Bug 76511 – [chromium] compositing tests with videos fail in chromium DumpRenderTree, seeking doesn't appear to work

• Component: Tools / Tests
• Status: RESOLVED FIXED

[James Robinson]

The following tests fail in chromium DRT:

compositing/geometry/clipped-video-controller.html
compositing/geometry/video-opacity-overlay.html
compositing/geometry/video-fixed-scrolling.html
compositing/overflow/scroll-ancestor-update.html
compositing/visibility/visibility-simple-video-layer.html
compositing/self-painting-layers.html
compositing/layers-inside-overflow-scroll.html
compositing/reflections/load-video-in-reflection.html

because seeking doesn't seem to work. specifically doing video.currentTime = 0 on a loaded video results in the video not showing up at all in chromium DRT.

[Eugene Nalimov]

Created attachment 124572 [details]
Patch

[Eric Carlson]

Comment on attachment 124572 [details]
Patch

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

> LayoutTests/platform/chromium/test_expectations.txt:3845
> +BUGWK76511 WIN : compositing/overflow/scroll-ancestor-update.html = TEXT

Shouldn't this failure have a new bug?

[WebKit Review Bot]

Comment on attachment 124572 [details]
Patch

Attachment 124572 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11369662

New failing tests:
compositing/overflow/scroll-ancestor-update.html
compositing/visibility/visibility-simple-video-layer.html

[Eugene Nalimov]

After discussion with James I re-run apple mac DRT with "-p" flag. (I run it before submitting the patch, but did not know that I should use "-p" flag for it to look at the pixel-level diffs...)

Unfortunately, now tests fail there -- looks that video moves to the next frame while 'seeked' event is being processed, so there is image mismatch once again. To tell the truth, expected PNG for at least one test -- /compositing/visibility/visibility-simple-video-layer -- does not make sense, it is *not* first frame in the video, though test tries to seek there. Both Chromium and Safari were not showing first frame, but they were showing different frames. With my change Chromium shows first frame, but Safari moves further before being stopped.

Looks that JS spec does not guarantee portable way to force specific video frame to be shown on screen -- see bug . The only way I can think is to use video with exactly the same frames... Maybe we can have different frames in the beginning, but identical near the end, and seek there?

[James Robinson]

What about a video file where every frame looks exactly the same (basically a picture that goes through the video display path)? That's what the compositing tests really want anyway.

[Eugene Nalimov]

After discussion with Ami looks there are several ways to proceed:
* play with 'paused' event, maybe it can guarantee the same frame is being displayed.
* or, use different expectations for different platforms.

[Aaron Colwell]

Created attachment 132314 [details]
Patch

[Aaron Colwell]

Comment on attachment 132314 [details]
Patch

I believe this patch will make the test behavior less timing sensitive. 

Rebaselines will still be needed in a follow-on patch because there appear to be unrelated scrollbar changes that need to be accounted for in the expectations.

[WebKit Review Bot]

Comment on attachment 132314 [details]
Patch

Clearing flags on attachment: 132314

Committed r111029: <http://trac.webkit.org/changeset/111029>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Aaron Colwell]

Reopening to attach new patch.

[Aaron Colwell]

Created attachment 132399 [details]
Patch

[Aaron Colwell]

Comment on attachment 132399 [details]
Patch

Rebaseline expectations to reflect scrollbar changes and consistent seeking

[James Robinson]

(In reply to comment #13)
> (From update of attachment 132399 [details])
> Rebaseline expectations to reflect scrollbar changes and consistent seeking

Please use a different bug for different patches or it makes it impossible to follow the bug history.  This bug is fixed, open a new one for baselines.

[James Robinson]

Comment on attachment 132314 [details]
Patch

This is the patch that landed, resetting flags for posterity.

[Aaron Colwell]

(In reply to comment #14)
> (In reply to comment #13)
> > (From update of attachment 132399 [details] [details])
> > Rebaseline expectations to reflect scrollbar changes and consistent seeking
> 
> Please use a different bug for different patches or it makes it impossible to follow the bug history.  This bug is fixed, open a new one for baselines.
 
Sorry about that.