569190 - startContainer returns parent node when double click is used to highlight a link

Status: UNCONFIRMED

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

Description

[Richard Griffiths]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

This problem is related to using range.startContainer in javascript. I've noticed that if you double click a link to highlight it then use range.startContainer it returns the links parent node. If you highlight a link by dragging then range.startContainer returns the text element as expected.
For example if you had the following html:

<p>some text <a href="#">some link</a> some more text</p>

Double clicking some highlights the whole link but range.startContainer will return the paragraph node.


Reproducible: Always

Steps to Reproduce:
1. Create a html page with the following body content

<script type="text/javascript">
function getselected() {
    alert(window.getSelection().getRangeAt(0).startContainer);
}
</script>

<div contentEditable="true">
<p>some text <a href="#">some link</a> some more text</p>
</div>

<input type="button" onclick="getselected()" value="Test it" />


2. Double click within the link to highlight it.

3. Click the Test it button and the alert will show [object HTMLParagraphElement]

4. Highlight the whole link by clicking and dragging

5. Click the Test it button and the alert will show [object Text]
Actual Results:  
Double clicking to highlight the link and clicking the Test it button returns the paragraph node not a text object.

Expected Results:  
Should return a text object.

Comment 1

[Kevin Brosnan]

Test case added to the url.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Clicking and dragging just selects the text.  Double-clicking selects the entire <a> node.  So of course the startContainer is different.

If your issue is with the latter behavior, then that's a selection issue, but it seems like the right behavior to me....

Comment 4

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

I intend to make the editing spec require that regardless of how the selection is created, the boundary point here has to be in the innermost wrapper, for a user-created selection.  I.e., foo{<b>bar</b> and foo[<b>bar</b> have to become foo<b>[bar</b>.  This is how WebKit already behaves.  I have other things I'm doing now, though, so I don't expect to get around to this too soon.  I want to fix up broken stuff I've already written before I add new broken stuff.  :)

See bug 688379 comment 12.

Comment 5

[Tim Down]

(In reply to :Aryeh Gregor from comment #4)
> I intend to make the editing spec require that regardless of how the
> selection is created, the boundary point here has to be in the innermost
> wrapper, for a user-created selection.  I.e., foo{<b>bar</b> and
> foo[<b>bar</b> have to become foo<b>[bar</b>.  This is how WebKit already
> behaves.  I have other things I'm doing now, though, so I don't expect to
> get around to this too soon.  I want to fix up broken stuff I've already
> written before I add new broken stuff.  :)
> 
> See bug 688379 comment 12.

Aryeh, did you ever get round to speccing this?

Comment 6

[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.