[Webkit-unassigned] [Bug 150365] New: [GTK] WebView flickers filled with a DIV's background color when AC is enabled

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=150365

            Bug ID: 150365
           Summary: [GTK] WebView flickers filled with a DIV's background
                    color when AC is enabled
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mario at webkit.org
                CC: bugs-noreply at webkitgtk.org, cgarcia at igalia.com,
                    cosimoc at gnome.org, mrobinson at webkit.org,
                    yoon at igalia.com, zan at falconsigh.net

Created attachment 263584
  --> https://bugs.webkit.org/attachment.cgi?id=263584&action=review
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151020/2ae2a401/attachment.html>