Changeset 178490 in webkit

Timestamp:

Jan 14, 2015, 11:59:09 PM (12 years ago)

Author:

Simon Fraser

Message:

Graphics corruption after Find on some pages
​https://bugs.webkit.org/show_bug.cgi?id=140489

Reviewed by Zalan Bujtas.

Source/WebCore:

After doing a Find on ​http://shop.outlier.cc/shop/retail/chino.html,
garbage could appear on some parts of the page. This is caused by creating
a compositing layer which is marked as opaque, yet failing to paint the entire
layer contents.

This was caused by a bug in RenderBox::computeBackgroundIsKnownToBeObscured()
logic. On the page in question, doing a Find could cause overflow:hidden sections
to get scrolled (since Find can reveal the selection by scrolling overflow).
However, the render tree walking under RenderBox::foregroundIsKnownToBeOpaqueInRect()
fails to take overflow scrolling into account, so gives the wrong answer
in some content configurations. As a result, we'd think that the background
is obscured, and never paint it.

Conservative fix is to have isCandidateForOpaquenessTest() return false
when the content has any non-zero scroll offset.

Tests: compositing/contents-opaque/opaque-with-scrolled.html

fast/backgrounds/opaque-scrolled-paint-background.html

• rendering/RenderBox.cpp:

(WebCore::isCandidateForOpaquenessTest):

LayoutTests:

Two new tests. The first one just reports that we have an opaque compositing
layer. The second one tests the the user-visible symptom of the missing
background.

• compositing/contents-opaque/opaque-with-scrolled-expected.txt: Added.
• compositing/contents-opaque/opaque-with-scrolled.html: Added.
• fast/backgrounds/opaque-scrolled-paint-background-expected.html: Added.
• fast/backgrounds/opaque-scrolled-paint-background.html: Added.

Location:

trunk

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• LayoutTests/compositing/contents-opaque/opaque-with-scrolled-expected.txt (added)
• LayoutTests/compositing/contents-opaque/opaque-with-scrolled.html (added)
• LayoutTests/fast/backgrounds/opaque-scrolled-paint-background-expected.html (added)
• LayoutTests/fast/backgrounds/opaque-scrolled-paint-background.html (added)
• Source/WebCore/ChangeLog (modified) (1 diff)
• Source/WebCore/rendering/RenderBox.cpp (modified) (1 diff)

trunk/LayoutTests/ChangeLog

@@ +1 @@
+2015-01-14  Simon Fraser  <simon.fraser@apple.com>
+
+        Graphics corruption after Find on some pages
+        https://bugs.webkit.org/show_bug.cgi?id=140489
+
+        Reviewed by Zalan Bujtas.
+        
+        Two new tests. The first one just reports that we have an opaque compositing
+        layer. The second one tests the the user-visible symptom of the missing
+        background.
+
+        * compositing/contents-opaque/opaque-with-scrolled-expected.txt: Added.
+        * compositing/contents-opaque/opaque-with-scrolled.html: Added.
+        * fast/backgrounds/opaque-scrolled-paint-background-expected.html: Added.
+        * fast/backgrounds/opaque-scrolled-paint-background.html: Added.
+
 2015-01-14  Alexey Proskuryakov  <ap@apple.com>
 

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2015-01-14  Simon Fraser  <simon.fraser@apple.com>
+
+        Graphics corruption after Find on some pages
+        https://bugs.webkit.org/show_bug.cgi?id=140489
+
+        Reviewed by Zalan Bujtas.
+        
+        After doing a Find on http://shop.outlier.cc/shop/retail/chino.html,
+        garbage could appear on some parts of the page. This is caused by creating
+        a compositing layer which is marked as opaque, yet failing to paint the entire
+        layer contents.
+        
+        This was caused by a bug in RenderBox::computeBackgroundIsKnownToBeObscured()
+        logic. On the page in question, doing a Find could cause overflow:hidden sections
+        to get scrolled (since Find can reveal the selection by scrolling overflow).
+        However, the render tree walking under RenderBox::foregroundIsKnownToBeOpaqueInRect()
+        fails to take overflow scrolling into account, so gives the wrong answer
+        in some content configurations. As a result, we'd think that the background
+        is obscured, and never paint it.
+        
+        Conservative fix is to have isCandidateForOpaquenessTest() return false
+        when the content has any non-zero scroll offset.
+
+        Tests: compositing/contents-opaque/opaque-with-scrolled.html
+               fast/backgrounds/opaque-scrolled-paint-background.html
+
+        * rendering/RenderBox.cpp:
+        (WebCore::isCandidateForOpaquenessTest):
+
 2015-01-14  Jer Noble  <jer.noble@apple.com>
 

trunk/Source/WebCore/rendering/RenderBox.cpp

@@ -1400 +1400 @@
             return false;
         if (childLayer->hasTransform() || childLayer->isTransparent() || childLayer->hasFilter())
+            return false;
+        if (!childBox.scrolledContentOffset().isZero())
             return false;
     }