New issue
Advanced search Search tips

Issue 678765 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

VTT Captions align and line properties conflict causing abrupt cutoff rather than wrap

Reported by cmulgan...@jwplayer.com, Jan 5 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce the problem:
Given the following VTT cue, see the screenshot attached for issue:
00:00:12.467 --> 00:00:14.167 align:middle line:16% position:10% size:78%
>> He always referred to her as

See test video - JW Player
http://qa.jwplayer.com/~randy/temp/cc_cutoff.html

Note: this also happens in a basic HTML5 Video tag - see screenshot "videotag"

What is the expected behavior?
Text should wrap to next line (see "expected" screenshot)

What went wrong?
Rather than wrap, text is being cut off ("cutoff" screenshot). Align:middle and position:10% seem to be conflicting. Changing position to 20% seems to solve the problem.

Did this work before? No 

Chrome version: 55.0.2883.95  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 24.0 r0

 With align:middle AND position:10%, the start position is 10% from the left edge of the screen and the text is aligned from the middle. A workaround we found would be if we change the value for either of these, the entire caption will show up:
position: auto (cue will be in the center of the screen)
align: start (cue will be aligned from the left of the screen)
 
videotag.png
121 KB View Download
cutoff.png
796 KB View Download
cutoff.vtt
2.1 KB Download
expected.png
497 KB View Download

Comment 1 by ajha@chromium.org, Jan 6 2017

Labels: Needs-Triage-M55
Components: -Blink Blink>Media>Video
Cc: kkaluri@chromium.org
Labels: hasbisect OS-Linux OS-Windows
Owner: e...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on Windows 10, Ubuntu 14.04  with chrome version 55.0.2883.87 and Mac 10.12.2 on chrome stable version 55.0.2883.95 and also in current canary version #57.0.2975.0
Issue is broken in M49.


Bisect Info:
===========
Good build : 49.0.2567.0,  Revision Range -360248
Bad build  : 49.0.2568.0,  Revision Range -360479

Unable to provide the CL's between good and bad, while bisecting using hasbisect(old) script has given only good builds.

On Manually looking at the CL's between good and bad builds:
============================================================
https://chromium.googlesource.com/chromium/src/+log/49.0.2567.0..49.0.2568.0?pretty=fuller&n=10000

The Suspecting change log is :
===============================
https://chromium.googlesource.com/chromium/src/+/122865bf39b087bfc1c7f29eff8bb7c240d7a616

From the above CL suspecting below change:
=========================================
Review URL: https://codereview.chromium.org/1452343002

eae@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Comment 4 by e...@chromium.org, Feb 21 2017

Status: WontFix (was: Assigned)
This will require a change in the video player as the spec mandates that break-word should be ignored when white-space pre/nowrap is specified.


Comment 5 by e...@chromium.org, Feb 21 2017

Owner: ----
Status: Untriaged (was: WontFix)
Err, it is WontFix from a Layout perspective but still an issue from a Video player issue (assuming it still repros for <video>)
If this isn't something that can be fixed here, can someone point in the right direction as to where to report the issue? Much appreciated!
Cc: mlamouri@chromium.org
Components: Blink>Media>Controls
Owner: steimel@chromium.org
Status: Assigned (was: Untriaged)
steimel@ - PTAL, thanks!
Status: WontFix (was: Assigned)
Currently working fine for me on Ubuntu 14.04 with chrome version 58.0.3029.110. I'll assume some unrelated CL landed that fixed this unless someone else can still repro.
Screenshot from 2017-05-09 16:25:16.png
455 KB View Download

Sign in to add a comment