Bug 150365 – [GTK] WebView flickers filled with a DIV's background color when AC is enabled

• Status: NEW
• Component: WebKitGTK

[Mario Sanchez Prada]

Created attachment 263584 [details]
Reduced test case

DESCRIPTION

In latest WebKit from trunk (tested with r191308), and probably for a while ago already (I think it happens with 2.8.3 as well), there seems to be a problem in WebKit2GTK when AC is enabled AND we have 3 animations where 2 of them happen SIMULTANEOUSLY and a 3rd one starts EXACTLY when the other 2 animations finish:

The WEBVIEW seems to FLICKER for a split second when the third animation starts, showing it COMPLETELY RENDERED with the same background colour defined via CSS for a DIV element. At the beginning I though it was just a "random flash", but after some testing and debugging I found that what is happening is that the webview gets filled with whatever the colour for that DIV element is, which is very weird.

You can see the BUG IN ACTION here:
https://drive.google.com/open?id=0BzYgG6C2skRsU3dlSnNUVVBXRU0

Perhaps this is related to bug 150344 (as I found it in exactly the same use case), but it's hard to tell for now.

What I can tell is a few THINGS I found to MAKE THE GLITCH HAPPEN (relative to the test case I'm attaching):
  * An IMAGE loaded with <IMG> over which we define an animation, and that IMG inside a DIV over which we defined another animation, and make both of them concurrent (same initial delay, same duration)
  * The 2 concurrent animations start with a non-zero delay (even it it's just 0.01)
  * The container DIV defines overflow: hidden
  * The animation for the container DIV defines animation-fill-mode = forwards
  * The two visible DIVs use ABSOLUTE (or fixed) positioning
  * The first visible DIV (the one defining the colour) is drawn right on top of of some text (positioning it so that it does not cover any text does not cause the glitch either)

Last, this does not happen every time I run the attached test case, but perhaps 7/10 times. Also, in a real life scenario it can be much worse since you can see many flickerings at the same time if there are concurrent animations happening (as it is in my case).

Also, note that this does not happen on OS X with the stable Safari (10601.1.56.2) nor with the latest Nightly build (I tried r191175) either, so it seems to be a bug exclusive to WebKitGTK+ (and maybe EFL) for some reason.


STEPS TO REPRODUCE

  1. Uncompress the contents of the attached file and load index.html in MiniBrowser
  2. You should see a round red image and some text explaining the issue with some text striked out at the top, covered by a div with a green coloured background on top of it.
  3. After 0.85s, you should see the round image shrinking which is, in fact, 2 concurrent animations at the same time:
    * One animation that makes the continer <DIV> shrink overflow:hidden shring
    * One animation that makes the <IMG> element shrink
  4. Right when those 2 animations finish, at 0.85s, a third animation  (not visible really, but it's there) starts, lasting for 0.85s more. 


EXPECTED OUTCOME:

No glitch should be seen when the last animation starts (step 4)


ACTUAL OUTCOME:

Very often, the web view flickers for a split second totally filled with the same colour of the background for the first DIV in the test case, causing a weird effect.

This does not always happen, though, so you might need to press Ctrl+R a few times.


FREQUENCY:

7/10

[Mario Sanchez Prada]

(In reply to comment #0)
> [...]
> DESCRIPTION
> 
> In latest WebKit from trunk (tested with r191308), and probably for a while
> ago already (I think it happens with 2.8.3 as well), there seems to be a
> problem in WebKit2GTK when AC is enabled AND we have 3 animations where 2 of
> them happen SIMULTANEOUSLY and a 3rd one starts EXACTLY when the other 2
> animations finish:

Quick message to expand this bug report with additional information after something I found today:

While I can reliably reproduce this both on my laptop and the original device where I saw the issue for the first time, both with Intel GPUs, I can tell that this did NOT happen on an ARM device with a Mali400 GPU (and the proprietary drivers for that), running exactly the same compiled version of WebKitGTK+.

That might suggest a problem related to the driver, perhaps only affects Intel GPUs after all. Knowing this, I think it would be great if someone out there with an NVIDIA card could try this test case out and report whether the bug is reproducible. Thanks!