Race condition in media track cue layout |
|||||
Issue descriptionI'm working on a code change that exposes a race condition inherent in this layout test: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/media/track/track-cue-rendering-after-controls-removed.html?q=third_party/WebKit/LayoutTests/media/track/track-cue-rendering-after-controls-removed.html Here's a demonstration of the race condition (visible on corp network only): http://wince.sfo.corp.google.com:8766/track-cue.html If I refresh that page repeatedly, I get consistent rendering of video3, with the cue text at the line=-2 position. However, the cue text for video1 randomly ends up at either the line=-1 or line=-2 position. The cue text for video2 is also racy, but is usually at the line=-2 position. Attached to this bug are screenshots showing various renderings. Here's the CL I have out that tickles this issue: https://codereview.chromium.org/2672833004/ I plan to mark the test as flaky so I can land the patch.
,
Feb 16 2017
+foolip +liberato Is this code one of you two is aware of?
,
Feb 16 2017
I don't know off-hand what this could be.
,
Feb 16 2017
Yeah, kind of hard to say off-hand what could be the trigger. It seems reasonable to assume that controls-induced cue layout reset is involved somehow. (I.e in case 3 the cue is always laid out with controls visible, pushing it up one; cases 1 and 2 seem to be laid out in a configuration where different values of 'controls' are observed.)
,
Feb 16 2017
Haven't managed to reproduce this locally (cues always end up at the bottom are some flashing of the controls.) Maybe sensitive to what transport is used too?
,
Feb 16 2017
My intent wasn't for someone to look at the race and find what it was but I'm looking for an owner for the bug :)
,
Feb 16 2017
i have no familiarity with track cue layout.
,
Feb 16 2017
re: comment #6 -- let me know if you want help reproducing this. It could, as you say, be sensitive to transport. I am running on the same linux host (wince.sfo) as the server, which is running vanilla apache. It also reproduces on the try bots. The video files it uses are copies of these files in the chromium repository: https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/LayoutTests/media/track/opera/track/webvtt/rendering/reftest/media/
,
Feb 21 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 21 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mlamouri@chromium.org
, Feb 15 2017