Bug 91756 – Incorrect scroll offset for RTL content after r123067

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Tony Chang]

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.

[Tony Chang]

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.

[Hironori Bono]

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

[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

[Tony Chang]

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?

[Hironori Bono]

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

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Hironori Bono]

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

[Tony Chang]

Comment on attachment 153965 [details]
Patch v1 (added rebaselined results)

Looks great, thanks!

[WebKit Review Bot]

Comment on attachment 153965 [details]
Patch v1 (added rebaselined results)

Clearing flags on attachment: 153965

Committed r123572: <http://trac.webkit.org/changeset/123572>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.