In http://trac.webkit.org/changeset/123067 , we tried to fix the scrollable content area. However, we start scrolled left the width of the scrollbar. This can be seen in the new failing layout tests: fast/block/float/026.html fast/block/float/028.html fast/overflow/unreachable-overflow-rtl-bug.html I'm going to mark those tests as failing for now.
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fblock%2Ffloat%2F026.html%2Cfast%2Fblock%2Ffloat%2F028.html%2Cfast%2Foverflow%2Funreachable-overflow-rtl-bug.html I'm going to update TestExpectations for this.
Created attachment 153447 [details] A reduced test case Greetings Tony, Apologies for this regression. (This regression is only for Chromium, right?) To investigate this issue on my PC, my r123067 outputs wrong scrollWidth values for several cases. (The attached page is an reduced test case. It shows a couple of div elements and compares their scrollWidth values.) This is caused by a couple of technical issues: changing clientLeft() carelessfully and forgetting removing unnecessary code. I will upload a fix after verifying this fix does not cause any more regressions. Regards, Hironori Bono
Created attachment 153759 [details] Patch v0 Greetings, To investigate this issue more deeply, my scrollbar changes may move positioned objects (in an RTL element) right up to three times. Moving positioned objects increases the scrollWidth values without changing the scrollLeft values. This makes scroll offsets look incorrect for these tests. Regards, Hironori Bono
Comment on attachment 153759 [details] Patch v0 View in context: https://bugs.webkit.org/attachment.cgi?id=153759&action=review > Source/WebCore/ChangeLog:19 > + Test: scrollbars/rtl/div-absolute.html > + Nit: Can you also list which other tests this will fix (e.g, fast/block/float/026.html, fast/block/float/028.html and fast/overflow/unreachable-overflow-rtl-bug.html)? Also, can you include the image results for one platform that shows the difference in the diff?
Created attachment 153956 [details] Patch v0' (for getting layout-test results from EWS bots) Greetings Tony, Many thanks for your review and comment. I have added rebaselined results for Windows. (Somehow, my Precise box is not trustworthy for getting rebaselined images and I would like to get Linux results from EWS bots.) Regards, Hironori Bono
Comment on attachment 153956 [details] Patch v0' (for getting layout-test results from EWS bots) Attachment 153956 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13334212 New failing tests: fast/block/float/028.html fast/block/float/026.html
Created attachment 153961 [details] Archive of layout-test-results from gce-cr-linux-07 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: gce-cr-linux-07 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Created attachment 153965 [details] Patch v1 (added rebaselined results) Greetings, Sorry for uploading changes so often. I have added rebaselined results for Linux retrieved from EWS bots. (New results do not have blanks at the right side of RTL elements.) Regards, Hironori Bono
Comment on attachment 153965 [details] Patch v1 (added rebaselined results) Looks great, thanks!
Comment on attachment 153965 [details] Patch v1 (added rebaselined results) Clearing flags on attachment: 153965 Committed r123572: <http://trac.webkit.org/changeset/123572>
All reviewed patches have been landed. Closing bug.