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
Possibly related to bug 85856 . I think the corresponding Chrome issue is: crbug.com/136078
oops, yes of course. wrong copy&paste
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.
Other browsers tested: WebKit nightly r122080 : OK Chrome Canary 22.0.1200.0 : FAIL So this is Chrome-only.
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 .
Thanks Bono-san, sorry - I just saw a new bug involving scrollbars and thought it might be related to your recent change.
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.
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
Created attachment 151267 [details] same video on YouTube
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.
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.
(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).
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
Please make future comments in the chromium issue instead since this doesn't seem like a WebKit bug.
(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 ***