Only the first line of a default positioned, multi-line cue is visible because the cue is placed too far down the page. I noticed this in the styling demo at http://www.longtailvideo.com/html5/webvtt/, where the cue at 46 seconds is: 00:00:46.000 --> 00:00:50.000 <c.myclass>This cue contains the class "myclass". Browsers that support ::cue CSS should make it red.</c> but only 'This cue contains the class "myclass". ' is visible.
<rdar://problem/13281078>
This works correctly with cues with default styles, but if the TextTrackCueBox element (-webkit-media-text-track-display) has style that increases it size, eg. -webkit-border-radius, the code that calculates the position is incorrect.
Created attachment 189966 [details] Screenshots (In reply to comment #2) > This works correctly with cues with default styles, but if the TextTrackCueBox element (-webkit-media-text-track-display) has style that increases it size, eg. -webkit-border-radius, the code that calculates the position is incorrect. I can't reproduce this properly, meaning that whatever I change I still get both lines displayed. I attached the screenshots. * Adding "font-size: 150%" to ::cue(.myclass) (works properly) * Adding "font-size: 150%" to -webkit-media-text-track-display (overlaps backgrounds) * Setting -webkit-border-radius on -webkit-media-text-tracks-all-nodes doesn't generate any visible differences (other than the cue background corners) It looks to me like the way a developer should change the font-size works (through ::cue), but it indeed looks like a bit of a problem for internally increasing the font-size of the cue.
Setting 'padding' on -webkit-media-text-track-display causes the problem I am seeing. Try adding this to a page with a <track>: video::-webkit-media-text-track-display { background-color:rgba(0, 0, 0, 0.5); padding: .4em !important; } I suspect that other CSS properties will also cause problems.
(In reply to comment #4) > Setting 'padding' on -webkit-media-text-track-display causes the problem I am seeing. Try adding this to a page with a <track>: Thanks! Took me a while to understand this (fairly simple) problem - it lies in RenderTextTrackCue::isOutside(), because padding (or border, margin), increases both horizontal and vertical sizes of the cue (thus the width is 100% + padding pixels) and isOutside always returns true with such properties. Due to the nature of the algorithm, if we allow padding and check only horizontal fitting in the parent container, the cue will be shifted upwards with multiples of line height (depending on the exact extra size besides the cue lines). Given that padding isn't really supported as VTT selector property, but we can set it via the pseudo-id, is the above described fix good enough? If there's a specific use-case for this, maybe a bug should be filed against the spec.
(In reply to comment #5) > (In reply to comment #4) > > Setting 'padding' on -webkit-media-text-track-display causes the problem I am seeing. Try adding this to a page with a <track>: > > Thanks! Took me a while to understand this (fairly simple) problem - it lies in > RenderTextTrackCue::isOutside(), because padding (or border, margin), increases > both horizontal and vertical sizes of the cue (thus the width is 100% + > padding pixels) and isOutside always returns true with such properties. > > Due to the nature of the algorithm, if we allow padding and check only horizontal > fitting in the parent container, the cue will be shifted upwards with multiples of line height (depending on the exact extra size besides the cue lines). > > Given that padding isn't really supported as VTT selector property, but we can > set it via the pseudo-id, is the above described fix good enough? If there's a > specific use-case for this, maybe a bug should be filed against the spec. I think the only use case is for UA specific styling. I found this because I am using 'padding' to make the "window" around the cue text (-webkit-media-text-track-display ) bigger to match a user style. See CaptionUserPreferencesMac::captionsStyleSheetOverride. I agree that we don't need to pages overriding private styles, so I don't this we need to request a spec change, but if we can support this without an enormous amount of work it will allow us to be more flexible internally.
Created attachment 190795 [details] Patch I think it's the simplest way to accomodate this
Comment on attachment 190795 [details] Patch Thank you Victor!
Comment on attachment 190795 [details] Patch Clearing flags on attachment: 190795 Committed r144443: <http://trac.webkit.org/changeset/144443>
All reviewed patches have been landed. Closing bug.
Re-opened since this is blocked by bug 111169
Created attachment 191003 [details] Resubmit patch The failing tests leading to the rollback aren't related to the changes
Comment on attachment 191003 [details] Resubmit patch Clearing flags on attachment: 191003 Committed r144508: <http://trac.webkit.org/changeset/144508>