(Copied from <http://crbug.com/85883>.) Chrome Version : 12.0.742.91 URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: - Firefox 4.x: OK IE 7/8/9: OK What steps will reproduce the problem? 1. Open the attached file with Chrome What is the expected result? The vertical scrollbar should be on the left side What happens instead? The vertical scrollbar is on the right side. Please provide any additional information below. Attach a screenshot if possible. This is another continuation of bug 54623, for the case of scrollbar on a multiple <select> element. Even though my r109537 moves the vertical scroll bar of the RenderLayer class to the left side, multiple <select> elements use the RenderListBox class to render their vertical scrollbars, i.e. my r109537 does not cover multiple <select> elements. To move the vertical scrollbar of a multiple <select> element, we need to change the RenderListBox class. Regards, Hironori Bono
Created attachment 154598 [details] Patch v0 Greetings, I have quickly written a change that changes the RenderListBox class to move the vertical scrollbars of RTL select elements. It may be better to add a pixel test? Regards, Hironori Bono
Comment on attachment 154598 [details] Patch v0 View in context: https://bugs.webkit.org/attachment.cgi?id=154598&action=review > Source/WebCore/rendering/RenderListBox.cpp:276 > + return LayoutRect(left, > additionalOffset.y() + borderTop() + paddingTop() + itemHeight() * (index - m_indexOffset), > contentWidth(), itemHeight()); Nit: I think the indent is meant to line up with the opening (.
(In reply to comment #1) > It may be better to add a pixel test? If no existing pixel test covers this, then it's probably worth adding one in addition to the JS test in the patch.
Created attachment 154864 [details] Patch v0' (for getting layout-test results from EWS bots) Greetings Tony, Many thanks for your quick review and approval. EWS bots notice that there are a couple of pixel tests for RTL select elements (fast/text/international/bidi-listbox.html and fast/test/international/bidi-listbox-atsui.html) and I have rebaselined these test images for Windows. (I'm going to get linux results from EWS bots and re-upload a change.) Regards, Hironori Bono
Comment on attachment 154598 [details] Patch v0 Cleared Tony Chang's review+ from obsolete attachment 154598 [details] so that this bug does not appear in http://webkit.org/pending-commit.
Comment on attachment 154864 [details] Patch v0' (for getting layout-test results from EWS bots) This patch is spinning in the cr-linux.
That's most often caused by flakiness. Your patch likely causes some set of tests to be flaky, causing the queue to fail to get consistent results and keep trying. Clearly a bug in the queue that this went on for days, but I think the patch will need modification to land.
Created attachment 160108 [details] Patch v0'' (for investigating why my change caused an infinite loop) Greetings, I would like to try my change (again) to investigate why my previous change caused an infinite loop. (This change adds rebaselined results to avoid it.) Regards, Hironori Bono
Looks like it's causing the ews bot to loop again: http://queues.webkit.org/patch/160108
Greetings Tony, Thanks for noticing it and sorry for disturbing you. I remember my new test depends on my fix for Bug 85856 and it fails without it. (I wonder why it causes an infinite loop, though.) Regards, Hironori Bono (In reply to comment #9) > Looks like it's causing the ews bot to loop again: http://queues.webkit.org/patch/160108
Any chance that work on this bug can continue?
Why WONTFIX?
(In reply to comment #12) > Why WONTFIX? Because it's Chromium specific and there is no longer Chromium development in WebKit. Move discussion to: https://code.google.com/p/chromium/issues/detail?id=85833