448424 - Word selection stop working if mouse goes over a combobox control

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Thierry Pierron]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Okay, the problem might be a little more complex than that, but it is the best way I found to reproduce it with FF 3.0.1.

Actually if there is a combobox, it seems all controls will stop the selection. 

Only tested on Windows XP.

Reproducible: Always

Steps to Reproduce:
1. double click to start word selection
2. move your mouse over a combobox
3. selection stop following mouse, leaving previously selected text as is.

Comment 1

[Thierry Pierron]

Attachment: Word selection seems broken with this page

Well, this bug seems not as reproducible as I thought. Still this sample works every time I try. Select some text, then move cursor over a control, selection stops following.

Comment 2

[Régis Caspar]

WORKSFORME with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1) Gecko/2008072310 Shiretoko/3.1a1

Comment 3

[Thierry Pierron]

Wow, you didn't seem to have try very hard. I can reproduce the problem with Firefox 3.1a on Mac OS X, Windows. Same problem with 3.0.1.

Using the example page, double click to start word selection on the word "pagination" for example, move your mouse (with LMB still pressed) over the controls. Eventually selection stops following mouse.

Comment 4

[Régis Caspar]

(In reply to comment #3)
> Wow, you didn't seem to have try very hard. I can reproduce the problem with
> Firefox 3.1a on Mac OS X, Windows. Same problem with 3.0.1.
You should not emit assumption on how hard or not I tried to reproduce, I did and it's not an obligation for me, I'm not paid for that. So you should be thankful when someone try to reproduce or help on bugs you submit 

> Using the example page, double click to start word selection on the word
> "pagination" for example, move your mouse (with LMB still pressed) over the
> controls. Eventually selection stops following mouse.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 ID:2008070208

Another computer, another mouse, I still cannot reproduce. I can move my selection (drag) over controls like selects and buttons for like 2 minutes !
Do you have a wireless mouse? Perhaps your mouse is defective? Can you try with another one?

If someone else than reporter can try to reproduce? 
=> qawanted

Comment 5

[Thierry Pierron]

Hold your horses, guy! I'm on the same boat...

Just it is so easy for me to reproduce on 4 completely different machines: several Win XP (same laptop actually), Win 2003, Mac OS X.4 and Mac OS X.5 with FF 3.0.1 and FF 3.1a, just a couple of second playing with the mouse on a plain Firefox install, without any extension.

Mice are just standard USB optical mouse, nothing very fancy.

Damn it, nobody else interested in testing the linked page for a few seconds? I can't believe I'm alone on this.

Comment 6

[cmtalbert]

WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a2pre) Gecko/20080825074258 Minefield/3.1a2pre

The selection breaks over the controls but doesn't stop for me.

Comment 7

[cmtalbert]

Can you try this in safe mode to see if this is an extension causing the behavior?

Comment 8

[Thierry Pierron]

Well, still no luck even in safe mode. Just to be sure once again, here is what I've done on the linked page :

* Double-click on "pagination" word
* Move mouse over one of the control ("Backup now" or edit field)
* Selection immediately stops following mouse.

Just tested on Firefox 3.0.1 (XP) and 3.1a (OS X.4).

Well, believe it or not, I've not yet seen an Firefox install that didn't shows this bug (well, apart FF 2 and below).

Comment 9

[Thierry Pierron]

Attachment: Example of bug effect

If it can be of any help, here is a screenshot of what it does : chunk of selection that sticks on the page. Even covering/uncovering the page where "old" selection is doesn't removes it. You have to select all, then deselect to clear everything.

Comment 10

[aravindm]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090301 Shiretoko/3.1b3pre
When text is typed continuously without any spaces, the cursor is going past the right edge but when the same text is typed with spaces, cursor moves to next line when it reaches right edge of the screen.

Comment 11

[Tyler Downer [He/Him]]

Reporter, please retest with Firefox 3.6.12 or later in a fresh profile (http://support.mozilla.com/kb/Managing+profiles). Also update your plugins (flash, adobe reader, java, quicktime, silverlight, etc.) Go to the developer's website and download the latest version from there. If you no longer see this issue, please close this bug as RESOLVED, WORKSFORME. If you do see the bug, please post a comment.

Comment 12

[Thierry Pierron]

Nope, still here. Tested with FF 3.6.12 on:
* Windows XP
* Windows 2008
* OS 10.4, 10.5 and 10.6

Actually every versions since 3.0 have exhibited this bug, no matter what extensions you have, or system you were running on.

Also try with Minefield 4.0b8 on OS 10.6, no add-ons, clean profile, etc..., still here. Seems like a bug of Gecko, not Firefox though.

Comment 13

[Aleksei Perepelkin [:chaos]]

WFM on Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0

But I can confirm this bug on older versions including latest Aurora. Though it's not exactly combobox, but text inputs. When you dragging pointer over input elements it's just stops.

Bug tested and confirmed:
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120713 Firefox/15.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1

Comment 14

[Jonah Ho (AAstar)]

I can confirm Aleksej's findings.  

I can reproduce this on the latest Aurora:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120624 Firefox/15.0a2
Windows 7 x64

Steps to reproduce:
1. Double-click on a text to start selection (do not let go of left mouse button after the second click)
2. Move the cursor over a textbox, then move the cursor to another word
3. Selection breaks  


Cannot reproduce on the latest Nightly:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0
Windows 7 x64

Steps taken
1. Double-click on a text to start selection (do not let go of left mouse button after the second click)
2. Move the cursor over a textbox, then move the cursor to another word
3. Selection continues

Comment 15

[Tracy Walker [:tracy]]

confirmed.

They key step here, as Jonah Ho pointed out, is to not release the mouse after the second click of word selection.

I can reproduce on latest Beta, Aurora and nightly

Comment 16

[Tracy Walker [:tracy]]

seems to break only on words after the "Backup Now" button.  Words before it can't reproduce the bug.

Comment 17

[[:Aleksej]]

(In reply to Tracy Walker [:tracy] from comment #16)
> seems to break only on words after the "Backup Now" button.  Words before it
> can't reproduce the bug.

That is since 2012-06-20-06-51-38…2012-06-21-03-05-36. [:chaos] found that the partial fix happened in bug 762764.

Comment 18

[(no longer active)]

Hmm, can you please elaborate on how exactly I can reproduce this bug?  Maybe I'm a bit confused, but selecting words after Backup Now using either single click and double click doesn't seem to result in this bug in the latest Nightly...

Comment 19

[[:Aleksej]]

(In reply to Ehsan Akhgari [:ehsan] from comment #18)

Double-click a word, and then, *without releasing*, drag to select more words across the button.

Comment 20

[Jonah Ho (AAstar)]

Hi Ehsan,

Steps to reproduce on Nightly:
1. Double-click the text "pagination" to start selection (do not let go of left mouse button after the second click)
2. Move the cursor past Backup Now, then move the cursor to another word
3. Selection breaks

Actual Results:
Unable to highlight any more words after moving past Backup Now.

Expected Results:
Able to highlight more words after moving past Backup Now.

This is interesting, I noted that:
With text above the Backup Now button selected initially, it works.
For example, double-click on "Settings" initially.
With text below the Backup Now button selected initially, it breaks.
For example, double-click on "pagination" initially.

Comment 21

[(no longer active)]

(In reply to Jonah Ho (FireChemist) from comment #20)
> Hi Ehsan,
> 
> Steps to reproduce on Nightly:
> 1. Double-click the text "pagination" to start selection (do not let go of
> left mouse button after the second click)
> 2. Move the cursor past Backup Now, then move the cursor to another word
> 3. Selection breaks
> 
> Actual Results:
> Unable to highlight any more words after moving past Backup Now.
> 
> Expected Results:
> Able to highlight more words after moving past Backup Now.
> 
> This is interesting, I noted that:
> With text above the Backup Now button selected initially, it works.
> For example, double-click on "Settings" initially.
> With text below the Backup Now button selected initially, it breaks.
> For example, double-click on "pagination" initially.

Ah, now I can reproduce it when selecting backwards over the Backup Now button.  Aryeh, can you please take a look?  My guess is that we're trying to peek inside the button frame, in which case the fix would be similar to that of bug 762764.

Also, does this happen with the drop-down boxes on the page as well?  I couldn't reproduce the bug with those...

Comment 22

[Jonah Ho (AAstar)]

For Nightly, the bug can only be reproduced with the Backup Now button.
For Aurora and earlier versions, the bug can be reproduced with both text boxes and the Backup Now button.  So I guess we don't have to worry about the text boxes.

Comment 23

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

(In reply to Ehsan Akhgari [:ehsan] from comment #21)
> Ah, now I can reproduce it when selecting backwards over the Backup Now
> button.  Aryeh, can you please take a look?  My guess is that we're trying
> to peek inside the button frame, in which case the fix would be similar to
> that of bug 762764.

I don't have any idea what this code is doing.  I tried mindless applying the fix from bug 762764 to nsHTMLButtonControlFrame without understanding what was going on, but it didn't seem to do anything.  I can try to take this bug, but only if you can tell me in some detail what things like PeekOffset() do.  For that matter, if there's high-level documentation of layout/, that would be a good start, because I don't even really know what frames are except in the most general sense . . .

Comment 24

[(no longer active)]

Sure.  PeekOffset is an API which lets you return a frame and an offset for moving the focus position on the frame tree.  For example, when you select a character and press Ctrl+Right, we end up calling PeekOffset on the text frame corresponding to that character and that handles the details of stepping inside frames or moving to the next ones in the frame tree etc.

The central place for all of this stuff is nsFrameSelection::MoveCaret.  That function handles the job of moving and/or extending the selection and updating the caret.  What I found out in bug 762764 was that we were traversing into the frames for the anonymous subtree of text controls when peeking into them (the default nsIFrame::PeekOffset implementation recurses into the frame tree.)

To debug this type of thing, I usually set a breakpoint in the MoveCaret function and walk my way down from there to see why the wrong frame gets picked up.  Let me know if this helps.

Comment 25

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.