442673 - event.rangeOffset on mouse events is returned when the cursor is not over text but in the vicinity of the text

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Elia]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

In some situations (for instance inside of a table cell) whenever you move the cursor in the vicinity of a line of text the mouse event generated by consequence (mousemove) reports a rangeParent and rangeOffset as if the cursor was directly over that text, even if it's just parallel to the text but in an empty space within the same html element.

Reproducible: Always

Steps to Reproduce:
1.Open up the page provided as the attachment testcase
2.Move the mouse over the empty space within the yellow cells in the table
3.Look at the information at the bottom of the table in the green box

(Note: javascript must be enabled)
Actual Results:  
As you can see rangeOffset is returned even if the cursor is not over the text but in a white space parallel to the equivalent character positions within the same html element (in this case, a table cell).

Expected Results:  
In the case the mouse move over an empty space no rangeParent should be returned or at least rangeOffset should be -1 to inform the user that no text range is currently being moved over by the mouse cursor.

Possibly related to:

#366416 - wrong rangeOffset in a wrapped span when double-clicking - https://bugzilla.mozilla.org/show_bug.cgi?id=366416

#409619 - Wrong event.rangeOffset breaks spellchecker - https://bugzilla.mozilla.org/show_bug.cgi?id=409619

Comment 1

[Elia]

Attachment: Test case for the rangeOffset bug

Comment 2

[Tuukka Tolvanen (sp3000)]

based on irc discussion this is about hovering under "sometext.ext" in particular. On (X11; U; Linux i686; en-US; rv:1.9.0.1pre) Gecko/2008062704 GranParadiso/3.0.1pre I get rangeParent=[object Text] rangeOffset=12 everywhere in the right cell, and matching text selection behaviour.

Comment 3

[Tuukka Tolvanen (sp3000)]

based on more irc discussion the issue is rather that rangeParent may be [object Text] when not actually on characters of said text (and rangeOffset being whatever relative to that)

Comment 4

[Elia]

Further discussion on IRC revealed that I forgot to mentions that all my concerns are about Text elements. So probably the best solution to this issue is as follows:

Expected Results:  
In the case the mouse moves over an empty space the rangeParent returned should be equal to the element that space belongs to (in the case above it should be a HTMLTableCellElement) and not a Text node.

Also based on this remark the issue shows up only when moving the mouse cursor over the second cell (the one on the right). I've added an updated testcase to show this in a better way.

Comment 5

[Elia]

Attachment: Test case for the rangeOffset bug [UPDATED]

Comment 6

[Elia]

Attachment: Test case for the rangeOffset bug with a more generalistic approach to mouse events target

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

The behavior seems to be the same with FF2.

I'm not sure this is a bug at all.
Offset 12 tells that mouse is after the end of the text.
If you move mouse above the text, offset is 0, telling that mouse is before the
text.
Other option for offset 12 case could be that rangeParent was TableCell with 
offset 1. But that tells just the same thing - mouse is after the text.

Comment 8

[Elia]

No, unfortunately it doesn't tell the same thing because it tells you the same whether your cursor is over the text or if it's just over a blank area which *also* contains the text (even if you're at a great distance from the text itself). And this is not the same if you want to react just when the user puts his cursor over a specific text and not just "near" the text.

For a concrete example of what I'm talking about you can have a look at my extension, QuietUrl (https://addons.mozilla.org/en-US/firefox/addon/5243), specifically the AutoUrl feature; which of course is the reason why I noticed and submitted this bug.

If it's not a bug, then it's a loss of functionality because there's no way of determining whether the cursor is precisely over some text, or to put it another way, you can't get to know which text is under the cursor.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #8)
> If it's not a bug, then it's a loss of functionality because there's no way of
> determining whether the cursor is precisely over some text, or to put it
> another way, you can't get to know which text is under the cursor.
I agree. 

Roc might have some comment to this, since the relevant code is probably 
nsIFrame::GetContentOffsetsFromPoint and/or hit testing

Comment 10

[Elia]

Also I noticed (just to have some kind of confirmation) that the Google toolbar suffers from this issue too. 
Specifically the Translate tool with the option to translate words you hover with the mouse on the fly from english to whatever is your native language. 

So it's not just me and I don't think there's a work around this as of now and it's strange that nobody noticed it so far. Or perhaps I'm the only one who had used that feature of the toolbar, being it disabled by default.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I guess we're returning where the caret would be if you clicked there.

I think it's reasonable for rangeOffset to work that way, since a lot of clients need that information. You probably want to do an additional check to see whether the mouse is actually inside the text node that's returned. Unfortunately that check is a little hard right now since text nodes don't support getClientRects(). This would be solvable if we supported getClientRects() on Ranges (bug 396392).

Comment 12

[Elia]

Attachment: Cursor position to reproduce the wrong selection

Comment 13

[Elia]

Well, then it means there's some of a problem in determining where the selection is going to start. 
For instance, try the last testcase I've uploaded (the one with the long title) and put your cursor exactly in the same spot as the black dot in the image I just uploaded. You'll notice that rangeOffset is always from 1 to 17 but whatever the number it corresponds to, if you click and drag to start a selection the entire div container gets selected and not just chars starting from the index indicated by the rangeOffset property.

Comment 14

[Elia]

I'm assuming that with "where the caret would be" you mean where the selection would start when clickdragging from that point. Otherwise I can't really find a use to know that piece of information.

Comment 15

[Elia]

Now that I'm on the bug tracker I'd though about asking if there were any updates in regard of this issue or #396392. Anything being worked on or discussed? Because I think this functionality is really needed to determine in a more accurate way text positioning.