Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050415 Firefox/1.0+ 1. Go to any site with a text box on the page, eg: www.google.com 2. Copy and paste this sentence into the textbox: "The quick red firefox jumps over the lazy IE this is a long sentence that is longer than the textbox is" 3a. Click anywhere in the textbox and try and highlight some text by dragging the mouse over it. 3b. With some text highlighted and the left mouse button kept pressed, move the mouse all the way to the right of the screen. Expected: Text is selected nicely Actual: The selected text goes mad. The position and the highlighting of the text is inconsistent. When moving the mouse out of the text box the cursor position no longer coresponds to what text is being highlighted. Also, whilst filing this bug (in the description textbox I am entering this text into) trying to highlight more than one line of text sometimes goes wonky too. Apologies for the vagueness of what is wrong, but it is hard to explain but very easy to see. Maybe fallout from 289792?
*** Bug 290468 has been marked as a duplicate of this bug. ***
Also (I suspect this is related, but perhaps it needs its own bug) 1. In this URL, left click and highlight all text starting from comment 0. 2. With the left mouse button still pressed (and text still highlighted) move the mouse to the bottom of the screen. 3. With the left mouse button still pressed, move the mouse from the bottom left of the screen to the bottom right of the screen. Notice lots of unnecessary scrolling/redrawing/page jumping.
Yes the google explaination is a bit poor. Let me try and clarify. 1. Paste a long sentence into the www.google.com textbox. 2. Place the caret at the start of the sentence. 3. Hold left mouse button so the text is becoming highlighted, and move the mouse right. 4. Keep the left mouse button held, and keep moving the mouse right. 5. Notice that the selected text jumps and highlights strangely. 6. Once all the text is highlighted and the mouse is at the very right of the screen (and the left mouse button still held), start moving the mouse to the left. 7. Notice that as the mouse approaches the right hand side of the text box, text in the box begins to unhighlight, even tho the mouse pointer isn't over said text.
seeing bug Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050415 wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050414 it regressed between BuildId 2005041411 and BuildId 2005041500 from tinderbox CREATURE I´ve used Status Whiteboard: above for testing with the string "The quick red firefox jumps over the lazy IE this is a long sentence that is longer than the textbox is" 1. paste into Status Whiteboard 2. click and hold somewhere into the string and drag mouse to the right. the text get highlighted from the starting point to the current cursor position. If the cursor leaves the box across the right border, text starts scrolling until all is seen. If you then move the cursor some pixels more to the right, the cursor jumps back to start position, and highlighting starts there again if you move the cursor outside the box further to the right. If you drag left, upon reentering the box the area between starting point and cursor position is highlighted again.
Forgot removing the teststring from the Status Whiteboard: The quick red firefox jumpsover the lazy IE this is a long sentence that is longer than the textbox is Another thing I noticed with this string in Status Whiteboard: click somewhere in the in the middle of the string, and don´t drag right, but just down out of the box, ans then drag left or right, key still pressed. If the string is left adjusted, i.e. start of string seen, behaviour is normal. If the string is scrolled, the selection area jumps when you leave the box.
Fixed by checkin for bug 290464
I'm seeing strange selection behaviour right now in this box when the portion of text is larger than this box. It is very difficult to select only a few lines. Firefox thinks that I want to scroll :? Previously I only saw what Kurt saw. Useragent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050418 Firefox/1.0+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050418 Firefox/1.0+ (Latest beast build) I am also still seeing strangeness. 1. Copy Comment 0 into the 'additional comments' textbox that is present in this bug report. 2. Copy it two or three times so the textbox is full up and you have scroll bars. 3. Move the vertical scroll bar into the middle position. 4. Click on some text in the middle of the textbox to begin highlighting. 5. With LMB still held, move the mouse down (below the textbox) and up (above the textbox) 6. Observe strange highlighting and response to mouse position.
Created attachment 181037 [details] new testcase (fail) I extended the value of the testcase input to 3 times the original length, causing select and drag to fail. I'm not sure if there is a limit set to the number of characters in the input. This may need need a new bug. Could you have a look Boris ?
(In reply to comment #14) additional: if you open the testcase , select&drag fails if you than hit the reload button (reload from cache) select&drag works.
Created attachment 181044 [details] new testcase (fail) testcase belonging to comment #13 in contrast to the previous testcase (<input type="text">) this one (<textarea>) isn't fixed by a reload
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050418 Firefox/1.0+ The most recent testcase still fails in the same way.
To clarify, the case where a single-lined textbox is full of text is fixed. With a multiple-line textbox (Like the 'additional comments' textbox in this page, or the testcase at https://bugzilla.mozilla.org/attachment.cgi?id=181044) this bug is still present.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050418 Firefox/1.0+ 14:21PDT confirming 1. testcase 2 is fixed by bug 290553 2. testcase 3 still fails
CC-> bzbarsky does the last testcase need a new bug Boris ?
That testcase probably does need a new bug, but I'm reopening this one because I'm lazy and the extended testcase does need its own fix (and we never had a fix in this bug anyway). I'll attach a patch.
Created attachment 181091 [details] [diff] [review] fix The offset returned by GetOffsetFromView is not trustworthy because it just sums the frame offsets up to the nearest parent with a view. This doesn't give you the true geometric offset.
Comment on attachment 181091 [details] [diff] [review] fix r+sr=bzbarsky, but shouldn't we check over other callers of GetOffsetFromView if they're using the offset for anything?
We should, yes, but not in this patch.
Comment on attachment 181091 [details] [diff] [review] fix cleaning up another event handling regression
*** Bug 290998 has been marked as a duplicate of this bug. ***
Comment on attachment 181091 [details] [diff] [review] fix a=asa
*** Bug 291683 has been marked as a duplicate of this bug. ***