1769320 - When double click in an editable element, Selection is extended outside the element

Status: NEW

(Core :: DOM: Selection, enhancement, P4)

Description

[Jimmy]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.54 Safari/537.36

Steps to reproduce:

1. Go to https://jsfiddle.net/gu8eb570/
2. Open the browser console
3. Double click on the link in the example text
4. Observe how anchorNode and focusNode is the text BEFORE and AFTER the link, rather than the actual link text.

Actual results:

Chromium and WebKit return references to the link text - I would expect Firefox to do the same, even though one could make the argument that the selection starts before the link and ends behind the link - although not very logical.

Expected results:

I would expect/prefer anchorText and focusNode to be a text node WITHIN the link element.

I love Firefox, but I'm not going to pollute our code with "if (firefox) { ... } else { ... }" like we did with Internet Explorer back in the day. Contrary to IE, Firefox does not have a market share that justifies this :-(

If you are worried that such changes will break code written against Firefox, then please provide a compatibility mode where we can opt for more modern behaviour.

Comment 1

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

Hi Masayuki,
I think this may be interesting to you and have your suggestion on severity and solutions. This looks being reported from a web developer.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Typically, double clicking in a link causes triggering the link so that the selection will not be available. And if the link is disabled by JS or something, and the visibility of the link is same as surrounding text, the behavior difference of the double clicking must look odd.

Additionally, users can always select link text with adding user-select: all into userContent.css, for example:

@-moz-document domain(example.com) {
  a[href]:not(:read-write) {
    user-select: all !important;
  }
}

I think that it does not make sense to change double click behavior only in <a href> element unless it causes not working some web apps.

On the other hand, it might be useful if the context menu has "Copy link text", but out of scope of this component.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ah, if only in the editable region, it may make sense.

Comment 4

[Jimmy]

I disagree with this issue being marked as an "enhancement". It's a compatibility problem, and it needs to be addressed as a bug. As mentioned, developers are probably not going to pollute code with if (firefox) to cater for Firefox users. Please search the bug tracker for getSelection(). It seems to me that the API needs a complete rewrite.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Jan might want to fix this when he works on around nsIFrame::PeekOffset.