Bug 72903 – [chromium] Layout Test compositing/geometry/clipped-video-controller.html is flaky on Win/Linux

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Adam Klein]

The following layout test is flaky on Chromium Linux and Windows.

compositing/geometry/clipped-video-controller.html

Flakiness dashboard:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Fclipped-video-controller.html

The diff is a single pixel of scrollheight:

-layer at (20,50) size 70x70 clip at (30,60) size 50x50 scrollWidth 352 scrollHeight 293
+layer at (20,50) size 70x70 clip at (30,60) size 50x50 scrollWidth 352 scrollHeight 292

There doesn't seem to be any culprit on the WebKit side. In Chromium, the timing lined up with http://src.chromium.org/viewvc/chrome?view=rev&revision=110733 (and thus I've CCed [e-mail]), but the test doesn't seem to have anything in particular to do with the canplaythrough event.  James mentioned on IRC that this failure might be due to timing, so I've CCed him as well in case he has further thoughts.

[Adam Klein]

Marked as PASS TEXT in http://trac.webkit.org/changeset/100941

[James Robinson]

The test uses the canplaythrough event to finish the test. I'm not sure why the render tree is different when this event is fired.

[Adam Klein]

(In reply to comment #2)
> The test uses the canplaythrough event to finish the test. I'm not sure why the render tree is different when this event is fired.

Ah, I got my tests mixed up (was looking at a different one that didn't mention canplaythrough).  I'm tempted to change this to use the 'canplay' event instead.

[Adam Klein]

Created attachment 116134 [details]
Patch

[Adam Klein]

Created attachment 116136 [details]
Remove expectation

[James Robinson]

I don't feel qualified enough on these events to know what the change does.  Can someone familiar with when these events fire and what might change the render tree please chime in with a theory of how this could help? I'd be happy to review officially if there's a valid-sounding story of how this could fix the test.

[Adam Klein]

Created attachment 116138 [details]
Use dumpAsText

[James Robinson]

Comment on attachment 116138 [details]
Use dumpAsText

View in context: https://bugs.webkit.org/attachment.cgi?id=116138&action=review

> LayoutTests/compositing/geometry/clipped-video-controller.html:23
> +      layoutTestController.dumpAsText();

this needs to be dumpAsText(true) or it won't produce any pixel output

[Adam Klein]

Created attachment 116140 [details]
dumpAsText(true)

[Adam Klein]

Comment on attachment 116138 [details]
Use dumpAsText

View in context: https://bugs.webkit.org/attachment.cgi?id=116138&action=review

>> LayoutTests/compositing/geometry/clipped-video-controller.html:23
>> +      layoutTestController.dumpAsText();
> 
> this needs to be dumpAsText(true) or it won't produce any pixel output

Done. Learn something new every day...

[Victoria Kirst]

(In reply to comment #6)
> I don't feel qualified enough on these events to know what the change does.  Can someone familiar with when these events fire and what might change the render tree please chime in with a theory of how this could help? I'd be happy to review officially if there's a valid-sounding story of how this could fix the test.

I don't know how this could cause a 1px rendering difference, but I can chime in on the timing: Chrome fires the canplay event fires at the beginning of playback, and as of last Friday Chrome fires the canplaythrough event when it believes it can play to the end of the video without stalling to buffer.

Previously, Chrome always fired canplay and canplaythrough at approx the same time, which goes against the html5 spec (crbug.com/73609). last Friday I checked in some code to fire canplaythrough at the media player's best guess.

So, I'm not sure why the rendering difference. It's true that canplay should be firing at the same time as always, and canplaythrough should be fired a bit later than before, but since this test uses a local video file, Chrome figures out very quickly that it can play through to the end without buffering and the canplaythrough event should be fired very close to the same time as it did in the past.

[Adam Klein]

Committed r100967: <http://trac.webkit.org/changeset/100967>