When working on bug 74779 I discovered that all the test cases I wrote (I tested the cases in bug 200537 to not spam the other) were failing on the EWS for Mac (which happens to run MacOS high-sierra), but this test cases are working fine on the Mac machine I have access to (that runs on Mojave). This tests also work fine on other ports (GTK and AppleWin). So now I believe there is an issue in high-sierra that causes that playing animated images to be broken. The issue I see is that the animated image doesn't play beyond the first 2 or 4 frames. It gets stuck playing. I'm attaching a patch with 3 simple test cases that pass fine on Mojave and WebKitGTK and AppleWin, but will fail here on the EWS because it runs high-sierra. I don't have the resources to investigate this, so I'm reporting this with the hope someone else can have a look.
Created attachment 375924 [details] Patch patch for testing. It includes 3 test cases that will fail on mac high-sierra but work on mojave or other ports
Created attachment 375925 [details] Patch same than above, just fix timeout value in a test
Comment on attachment 375925 [details] Patch Attachment 375925 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/12885592 New failing tests: fast/images/draw-animated-image-simple-no-repeat.html fast/images/count-animated-image-frames-simple-timer.html fast/images/count-animated-image-frames-decode-and-webkitImageFrameReady.html
Created attachment 375931 [details] Archive of layout-test-results from ews103 for mac-highsierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-highsierra Platform: Mac OS X 10.13.6
This might be related to [window setAutodisplay:NO] in DumpRenderTree that will prevent the repaint-based advancement of animated images. A hack would be to add a composited element on the page to turn autodisplay on.
(In reply to Simon Fraser (smfr) from comment #5) > This might be related to [window setAutodisplay:NO] in DumpRenderTree that > will prevent the repaint-based advancement of animated images. > > A hack would be to add a composited element on the page to turn autodisplay > on. I had no idea this was a thing. Let's try it.
Created attachment 375935 [details] Patch Add <div style="will-change: transform"> to the 3 tests
We should really add testRunner.setWindowAutodisplay() or something.
(In reply to Carlos Alberto Lopez Perez from comment #6) > (In reply to Simon Fraser (smfr) from comment #5) > > This might be related to [window setAutodisplay:NO] in DumpRenderTree that > > will prevent the repaint-based advancement of animated images. > > > > A hack would be to add a composited element on the page to turn autodisplay > > on. > > I had no idea this was a thing. > > Let's try it. This fixed the issue I was having :) What its the rationale for having a default of [window setAutodisplay:NO] in DRT? Just curious.
(In reply to Carlos Alberto Lopez Perez from comment #9) > (In reply to Carlos Alberto Lopez Perez from comment #6) > > (In reply to Simon Fraser (smfr) from comment #5) > > > This might be related to [window setAutodisplay:NO] in DumpRenderTree that > > > will prevent the repaint-based advancement of animated images. > > > > > > A hack would be to add a composited element on the page to turn autodisplay > > > on. > > > > I had no idea this was a thing. > > > > Let's try it. > > This fixed the issue I was having :) > > What its the rationale for having a default of [window setAutodisplay:NO] in > DRT? Just curious. Historically, it increased performance, and made testing more predictable (you only paint when you explicitly ask for it).
(In reply to Simon Fraser (smfr) from comment #10) > > What its the rationale for having a default of [window setAutodisplay:NO] in > > DRT? Just curious. > > Historically, it increased performance, and made testing more predictable > (you only paint when you explicitly ask for it). I see. But I have to say that I find really confusing that a test can behave differently in WK2 and WK1 due to this setting. Maybe the default should be the other way around, so only tests that really need this disabled have to manually opt-in. In any case, I'm not going to argue/push about changing this as I'm not really interested into WebKit1 development. I'm closing this as an invalid bug. Thanks!