Bug 90761 – [Chromium] Selection issues in RTL pages with horizontal scrollbar

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Yair Yogev]

Created attachment 151200 [details]
a video showing the issue

0. Make sure you use Pepper Flash
1. Enter 
http://forum.bgu.co.il/index.php?showtopic=340065
2. Zoom in to get a horizontal scrollbar (or make the window narrow enough)
3. Try to select text as shown in the video

What is observed:
1. There is a big gap between where the selection started and the position of the mouse when the visual selection started to appear.
2. The gap size depends on the size of the horizontal scrollbar (a bigger zoom or a smaller window, equals a bigger gap)
3. When i selected from the left, although lagged behind, the selection appeared where i clicked (just not *when* i clicked).
4. but when i selected from the right, the selection appeared pretty far from where i initially clicked
5. This is just visual- the real selection is correct. If i copy&paste or try to drag part of the text that was supposed to be selected, you can see the real selection did start where i clicked.
6. I also dragged the selection downwards to the next line, and then upwards to the same line to continue my selection. Doing so made parts of the blue selection markings stay on the screen even after the text is no longer selected. You can accumulate these selection residues on screen by playing with this behavior some more.

Chrome issue: http://crbug.com/21225

I reproduced the issue under Windows7 with latest Chrome Canary build
(wchich currently means
Google Chrome	22.0.1200.0 (145632) canary
OS	Windows
WebKit	537.1 (@121899)
JavaScript	V8 3.12.9
Flash	11.3.31.213

[Jeremy Moskovich]

Possibly related to bug 85856 .

I think the corresponding Chrome issue is: crbug.com/136078

[Yair Yogev]

oops, yes of course. wrong copy&paste

[Jeremy Moskovich]

I can reproduce this on Chrome/Mac 21.0.1180.15 (the current dev channel release) which AFAIK doesn't have Pepper flash enabled.

Selection works fine as long as the horizontal scrollbar isn't displayed but the bug reproduces if I shrink the Window enough for the scrollbar to display.

I think this is a bug in WebKit selection code and has nothing to do with Pepper flash.

We need to bisect to see where this broke.

[Jeremy Moskovich]

Other browsers tested:
WebKit nightly r122080 : OK
Chrome Canary 22.0.1200.0  : FAIL

So this is Chrome-only.

[Hironori Bono]

Greetings Jeremy,

Thanks for your bug report.
Bug 85856 changes the position of vertical scrollbars (not horizontal scrollbars) of editable elements, i.e. content-editable <div> elements and <textarea> ones. So, my change should not cause problems for pages that do not have these elements, i.e. pages that Chrome shows its vertical scrollbars to the right side. (In fact, when I open this page with Chrome, Chrome shows its vertical scrollbar to the right side.)

Regards,

Hironori Bono

(In reply to comment #1)
> Possibly related to bug 85856 .

[Jeremy Moskovich]

Thanks Bono-san,

sorry - I just saw a new bug involving scrollbars and thought it might be related to your recent change.

[Ryosuke Niwa]

I can't see the video. What kind of format is this?

Could someone tell me how the selection is done? Also, this bug title is unacceptably vague.

[Yair Yogev]

it's an Xvid. i uploaded it to YouTube so it should now be accessible to everyone:
http://www.youtube.com/watch?v=2o-bG3Jz1_s

[Yair Yogev]

Created attachment 151267 [details]
same video on YouTube

[Ryosuke Niwa]

Yeah I think I can reproduce the same issue on Chrome 20. But I can't reproduce it on the latest trunk build: http://download-chromium.appspot.com/

It seems like there are multiple things going wrong on this page but none of that reproduce on the trunk builds.

[Yair Yogev]

How about canary builds?
under Windows 7, for me it doesn't reproduce in ToT chromium but it does in Canary Chrome.
also, it no longer happens if i disable Pepper Flash
Jeremy reported reproducing it without Pepper Flash though in Mac.

[Ryosuke Niwa]

(In reply to comment #11)
> How about canary builds?
> under Windows 7, for me it doesn't reproduce in ToT chromium but it does in Canary Chrome.

Interesting. That probably means that this isn't a WebKit bug. I also see that all interaction with the page is extremely slow (e.g. selection draws half a second after to where my mouse was dragged).

[Yair Yogev]

Yes the slow selection is noticeable.

some more URLs showing the same problem if the window is narrow enough (or content zoomed enough) to have a horizontal scrollbar:

http://www.hnn.co.il/news_article93081.html
http://www.news1.co.il/Archive/001-D-303773-00.html
http://www.jcpa.org.il/JCPAHeb/Templates/showpage.asp?FID=865&DBID=1&LNGID=2&TMID=178&IID=26953
http://www.dwh.co.il/content/microsoft/125-%D7%9E%D7%99%D7%A7%D7%A8%D7%95%D7%A1%D7%95%D7%A4%D7%98-microsoft/1963-SSIS-Integration-Toolkit-for-Microsoft-Dynamics-CRM

so it's not something too specific to that page, it affects many Israeli pages

[Ryosuke Niwa]

Please make future comments in the chromium issue instead since this doesn't seem like a WebKit bug.

[Adrienne Walker]

(In reply to comment #14)
> Please make future comments in the chromium issue instead since this doesn't seem like a WebKit bug.

...

*** This bug has been marked as a duplicate of bug 91155 ***