RESOLVED FIXED 60741
Incorrect RenderLayer transforms on overflow RTL pages
https://bugs.webkit.org/show_bug.cgi?id=60741
Summary Incorrect RenderLayer transforms on overflow RTL pages
Adrienne Walker
Reported 2011-05-12 18:33:24 PDT
On pages with dir=rtl, compositing, and a horizontal scrollbar, composited layers get incorrect transforms and bounds. Without any horizontal overflow, the composited case appears identical to the software case. At the very least, http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderLayerCompositor.cpp#L444 assumes that the content origin is at 0, so when boundingBoxRect.x() is negative, that calculation ends up with a very large bound. I will attach some test cases to demonstrate this issue by resizing the window. Compare the composited cases (with and without a horizontal scrollbar) to the software cases.
Attachments
Test case: compositing, fixed position layer (343 bytes, text/html)
2011-05-12 18:34 PDT, Adrienne Walker
no flags
Test case: software, fixed position layer (298 bytes, text/html)
2011-05-12 18:34 PDT, Adrienne Walker
no flags
Test case: compositing, absolute position layer (346 bytes, text/html)
2011-05-12 18:35 PDT, Adrienne Walker
no flags
Test case: software, fixed position layer (301 bytes, text/html)
2011-05-12 18:35 PDT, Adrienne Walker
no flags
Patch (50.82 KB, patch)
2011-06-23 14:23 PDT, Adrienne Walker
no flags
Patch (51.71 KB, patch)
2011-06-23 15:17 PDT, Adrienne Walker
no flags
Patch (52.11 KB, patch)
2011-06-24 11:13 PDT, Adrienne Walker
simon.fraser: review+
Adrienne Walker
Comment 1 2011-05-12 18:34:29 PDT
Created attachment 93380 [details] Test case: compositing, fixed position layer
Adrienne Walker
Comment 2 2011-05-12 18:34:44 PDT
Created attachment 93381 [details] Test case: software, fixed position layer
Adrienne Walker
Comment 3 2011-05-12 18:35:01 PDT
Created attachment 93382 [details] Test case: compositing, absolute position layer
Adrienne Walker
Comment 4 2011-05-12 18:35:42 PDT
Created attachment 93383 [details] Test case: software, fixed position layer
mitz
Comment 5 2011-05-20 15:16:33 PDT
Adrienne Walker
Comment 6 2011-06-23 14:23:33 PDT
Adrienne Walker
Comment 7 2011-06-23 14:25:18 PDT
I will also mention that I have an in-progress patch that reenables compositing for rtl pages in Chromium. With that patch in place, these tests pass in Chromium. I just wanted to fix this underlying general WebKit bug first before committing that code.
Simon Fraser (smfr)
Comment 8 2011-06-23 14:25:31 PDT
Comment on attachment 98402 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=98402&action=review > LayoutTests/compositing/rtl/rtl-absolute-overflow-scrolled.html:54 > + <!-- green square should appear at 50,50 from the top left --> > + <div id="layer"></div> It's better if red shows on failure. Can you put a red box under the green one that would be exposed on failure in all the tests?
James Robinson
Comment 9 2011-06-23 14:26:43 PDT
Comment on attachment 98402 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=98402&action=review > Source/WebCore/ChangeLog:9 > + Fix positioning of the root graphics layer for RTL pages. The fact > + the left side of the page is negative for pages with overflow is not I think you accidentally a word ("The fact the left side..")
Adrienne Walker
Comment 10 2011-06-23 15:17:38 PDT
Adrienne Walker
Comment 11 2011-06-23 15:19:04 PDT
(In reply to comment #10) > Created an attachment (id=98418) [details] > Patch Grammar fixed. The tests now have non-composited red indicator elements positioned identically underneath the composited green layers.
Adrienne Walker
Comment 12 2011-06-23 16:14:09 PDT
Simon Fraser (smfr)
Comment 13 2011-06-23 16:33:02 PDT
Can you list some real-world sites that are affected by this change?
Adrienne Walker
Comment 14 2011-06-23 17:04:45 PDT
(In reply to comment #13) > Can you list some real-world sites that are affected by this change? This could very plausibly trigger on Gmail in Hebrew. If there's an embedded video in a message, the Gmail fixed position "archive spam delete etc" header could overlap it, become composited, and would then draw entirely incorrectly.
Adrienne Walker
Comment 15 2011-06-23 17:22:25 PDT
Adrienne Walker
Comment 16 2011-06-23 17:59:56 PDT
Reverted r89632 for reason: Breaks ancestor-overflow-change unexpectedly Committed r89645: <http://trac.webkit.org/changeset/89645>
Adrienne Walker
Comment 17 2011-06-23 18:03:12 PDT
(In reply to comment #16) > Reverted r89632 for reason: > > Breaks ancestor-overflow-change unexpectedly > > Committed r89645: <http://trac.webkit.org/changeset/89645> I thought I had tested this on Safari, but I missed it and it's skipped on Chromium Linux. I will fix this issue and reupload. Sorry for the hassle. :)
Adrienne Walker
Comment 18 2011-06-24 11:13:27 PDT
Adrienne Walker
Comment 19 2011-06-24 11:18:46 PDT
(In reply to comment #18) > Created an attachment (id=98514) [details] > Patch Now with fewer test breakages and some additional skipped tests on Chromium Mac. This ran cleanly on Linux Chromium-GPU and on Snow Leopard Safari. Root graphics layers need to be adjusted so that their position is zero and their offset is the left of the document. The previous patch was using the local compositing bounds for the adjustment and not the document rect, which was not quite the right value in all cases.
Adrienne Walker
Comment 20 2011-06-24 11:35:23 PDT
Adrienne Walker
Comment 21 2011-06-24 12:16:59 PDT
Note You need to log in before you can comment on or make changes to this bug.