Texttrack cues are not constrained to the video
Reported by
thomas...@googlemail.com,
Mar 22 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Play the video in the supplied example. You will see the text cues move down the screen until they disappear first partially then completely. What is the expected behavior? All other browsers I have tested (Firefox 59, Safari 11) ensure that the cue box doesn't leave the video's rendering area. What went wrong? If I read the standard correctly I think the browser should ensure that the cue boxes are constrained to the videos rendering area: https://w3c.github.io/webvtt/#processing-cue-settings (step 11 > If cue’s WebVTT cue snap-to-lines flag is false > 4) "If there is a position to which the boxes in boxes can be moved while maintaining the relative positions of the boxes in boxes to each other such that none of the boxes in boxes would overlap any of the boxes in output, and all the boxes in boxes would be within the video’s rendering area, then move the boxes in boxes to the closest such position to their current position, and then jump to the step labeled done positioning below" Did this work before? No Does this work in other browsers? Yes Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.13.3 Flash Version:
,
Mar 23 2018
thomask42@ Thanks for the issue. Tested this issue on Mac OS 10.13.3. and Windows 10 on the reported version 65.0.3325.181, latest Canary 67.0.3379.0 and M60 build by following the below steps. 1. Launched Chrome and opened by the given html file. 2. Played the video and can observe that the texttrack cue moves down the video and can see it chopped at 100% on Chrome. This is observed from M-60 chrome builds. This behavior is not observed on Firefox. Attached is the screen cast and screen shots for reference. Can you please check and confirm if this is the issue you are seeing? Thanks..
,
Mar 23 2018
Yes, this is the issue I'm seeing. In my tests the cue is only partially visible at "line: 90%" and completely off screen at 100% though.
,
Mar 23 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 4 2018
,
Apr 5 2018
Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome reported version #65.0.3325.181 and latest canary #67.0.3388.0. Bisect Information: ===================== Good build: 64.0.3257.0 Bad Build : 64.0.3258.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/65c2ce1ca7982e79650154f609785e2b4fcc46fc..e6b16d301f0da8a22bfba7ab5997771af0459cf5 From the above change log suspecting below change Change-Id: I1063b940db81555a65211fa93e84441b53e2b091 Reviewed-on: https://chromium-review.googlesource.com/753102 srirama.m@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Apr 5 2018
This is essentially a dupe of issue 314037 - prior to the commit above, the position would be computed in a different way (following some old spec revision) and thus not be as affected by the lack of "overlap avoidance" as the current position computation is.
,
Apr 5 2018
Confirmed locally that the bisect is correct. @fs, should we revert it for now or is it ok to continue with this behavior for now and then fix the issue 314037 later?
,
Apr 5 2018
We should probably check for common ground and let that guide the decision (i.e check what Firefox does.)
,
Apr 5 2018
Though the spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=22029 is still open and there isn't much traction for sometime.
,
Apr 5 2018
Firefox is adjusting/pushing the cues inside the video viewport when they are about to go out of video viewport(cues 9 and 10). I will try if we can do the same as a feasible solution for now.
,
Apr 10 2018
@fs, shall i implement the "If cue’s WebVTT cue snap-to-lines flag is false" section of the "apply-webvtt-cue-settings" algorithm (https://w3c.github.io/webvtt/#apply-webvtt-cue-settings sans line-align step as a temporary solution for this. Line-align has been implemented and reverted before and that will reland once the spec bug https://github.com/w3c/webvtt/issues/425 is concluded. Or is it better to wait till the line-align changes go? WDYS?
,
Apr 10 2018
If you want to implement "overlap avoidance" (issue 314037) - sans lineAlign - feel free to do so. Since lineAlign essentially only does an adjustment before the actual overlap checking it shouldn't be problematic to leave it out. Another option would of course be to revert the change above, and then reland together with the other changes (overlap avoidance, lineAlign).
,
Apr 10 2018
ok, i will revert the above change first and work on it later .
,
Apr 10 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by susan.boorgula@chromium.org
, Mar 23 2018