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.
Created attachment 124572 [details] Patch
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?
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
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?
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.
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.
Created attachment 132314 [details] Patch
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.
Comment on attachment 132314 [details] Patch Clearing flags on attachment: 132314 Committed r111029: <http://trac.webkit.org/changeset/111029>
All reviewed patches have been landed. Closing bug.
Reopening to attach new patch.
Created attachment 132399 [details] Patch
Comment on attachment 132399 [details] Patch Rebaseline expectations to reflect scrollbar changes and consistent seeking
(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.
Comment on attachment 132314 [details] Patch This is the patch that landed, resetting flags for posterity.
(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.