Bug 168660

Summary: REGRESSION(~r212322): LayoutTest media/track/track-cue-container-rendering-position.html is a flaky timeout
Product: WebKit Reporter: Ryan Haddad <ryanhaddad>
Component: MediaAssignee: Per Arne Vollan <pvollan>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, bfulgham, eric.carlson, jer.noble, pvollan, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
eric.carlson: review+
Patch none

Attachments
Patch (2.26 KB, patch)
2017-03-29 05:38 PDT, Per Arne Vollan
no flags
Patch (2.28 KB, patch)
2017-03-29 06:38 PDT, Per Arne Vollan
eric.carlson: review+
Patch (2.75 KB, patch)
2017-03-29 22:16 PDT, Per Arne Vollan
no flags
Alexey Proskuryakov
Comment 1 2017-02-26 18:05:37 PST
First occurrence in r212322. Not sure if it can be the culprit, unless it messed up some feature initialization flags. But even if this change is not to blame, this was definitely broken not long before - the test was absolutely stable earlier, and fails very often now. The test fails especially often on slower bots (ASan, leaks, GuardMalloc). @@ -1,7 +1,7 @@ +CONSOLE MESSAGE: line 83: No text track cue with display id '-webkit-media-text-track-display' is currently visible +FAIL: Timed out waiting for notifyDone to be called The top of the text track container should be in the bottom 30% of the video element. EVENT(canplaythrough) -EXPECTED (cueDisplayElement.offsetTop > (video.videoHeight * .70) == 'true') OK -END OF TEST
Radar WebKit Bug Importer
Comment 2 2017-02-26 18:06:11 PST
Per Arne Vollan
Comment 3 2017-03-27 03:51:46 PDT
I am unable to reproduce this timeout with a debug ASAN build.
Per Arne Vollan
Comment 4 2017-03-29 05:38:51 PDT
Per Arne Vollan
Comment 5 2017-03-29 06:38:48 PDT
Eric Carlson
Comment 6 2017-03-29 06:43:58 PDT
Comment on attachment 305729 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=305729&action=review > LayoutTests/media/track/track-cue-container-rendering-position.html:25 > + } catch (exception) { I think it would be better to try this a finite number of times and fail with an error message instead of having the test timeout in the event of an error.
Per Arne Vollan
Comment 7 2017-03-29 22:16:21 PDT
Per Arne Vollan
Comment 8 2017-03-29 22:55:31 PDT
(In reply to Eric Carlson from comment #6) > Comment on attachment 305729 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=305729&action=review > > > LayoutTests/media/track/track-cue-container-rendering-position.html:25 > > + } catch (exception) { > > I think it would be better to try this a finite number of times and fail > with an error message instead of having the test timeout in the event of an > error. Thanks for reviewing! I will update the patch.
Per Arne Vollan
Comment 9 2017-03-29 23:37:33 PDT
Eric Carlson
Comment 10 2017-03-30 08:52:46 PDT
Comment on attachment 305834 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=305834&action=review > LayoutTests/media/track/track-cue-container-rendering-position.html:14 > + var maxRetries = 256; This means the test won't fail for 25 seconds. What made you choose such a long time, it seems *extremely* unlikely that it could take that long for the cue display element to be created.
Note You need to log in before you can comment on or make changes to this bug.