Bug 103271 - [EFL][Qt][WK2] Tiles not always painted
Summary: [EFL][Qt][WK2] Tiles not always painted
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mikhail Pozdnyakov
Depends on:
Blocks: 101288 103105
  Show dependency treegraph
Reported: 2012-11-26 10:15 PST by Kenneth Rohde Christiansen
Modified: 2012-12-04 06:39 PST (History)
11 users (show)

See Also:

Issue (53.67 KB, image/png)
2012-11-26 10:16 PST, Kenneth Rohde Christiansen
no flags Details
Test case (5.02 KB, text/html)
2012-11-27 06:09 PST, Kenneth Rohde Christiansen
no flags Details
patch (2.02 KB, patch)
2012-11-27 08:40 PST, Mikhail Pozdnyakov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Rohde Christiansen 2012-11-26 10:15:31 PST
Run https://bug-103081-attachments.webkit.org/attachment.cgi?id=175962 with WEBKIT_SHOW_COMPOSITING_DEBUG_VISUALS=1

Resize window to be smaller than one tile.
Now resize to be bigger than 1 tile in height and 2 tiles in width.

result: third tile row in in x-direction is not there.
Comment 1 Kenneth Rohde Christiansen 2012-11-26 10:16:54 PST
Created attachment 176026 [details]
Comment 2 Kenneth Rohde Christiansen 2012-11-27 03:32:46 PST
To be able to easily reproduce, add the follwing patch:

@@ -377,6 +377,8 @@ void TiledBackingStore::computeCoverAndKeepRect(const IntRect& visibleRect, IntR
     coverRect = visibleRect;
     keepRect = visibleRect;
+    return;

The bug is in 

@@ -196,6 +196,8 @@ void PageViewportController::didChangeViewportSize(const FloatSize& newSize)
     // it can resize the content accordingly.

Which sync'ed the visible content before the new fixed layout size has been applied in the web process.
Comment 3 Kenneth Rohde Christiansen 2012-11-27 06:09:29 PST
Created attachment 176251 [details]
Test case
Comment 4 Mikhail Pozdnyakov 2012-11-27 08:40:57 PST
Created attachment 176274 [details]
Comment 5 Kenneth Rohde Christiansen 2012-11-27 08:42:48 PST
Comment on attachment 176274 [details]

Didn't this fix some layout tests?
Comment 6 Jocelyn Turcotte 2012-11-27 08:53:12 PST
Comment on attachment 176274 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=176274&action=review

> Source/WebKit2/ChangeLog:8
> +        The problem turned up because visible content was synchromized before the new fixed

synchromized -> syncronized
Comment 7 WebKit Review Bot 2012-11-27 09:03:26 PST
Comment on attachment 176274 [details]

Clearing flags on attachment: 176274

Committed r135864: <http://trac.webkit.org/changeset/135864>
Comment 8 WebKit Review Bot 2012-11-27 09:03:31 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Chris Dumez 2012-12-04 05:35:29 PST
I spent a while using git bisect and it turns out that this patch seems to be causing failures in several css-sticky test cases.

Try for example the following:
WebKitBuild/Debug/bin/MiniBrowser LayoutTests/fast/css/sticky/inflow-sticky.html

The output will be wrong (no blue stripe).

Then try to resize the window, it will repaint and the blue stripe will appear.
The output will then match the one in the -expected.html.
Comment 10 Chris Dumez 2012-12-04 06:39:25 PST
You can also test http://html5-demos.appspot.com/static/css/sticky.html

You'll see that the sticky element does not behave as expected. It gets repositioned only when you resize the window. It is pretty broken.