Bug 35141 – Double-click selects the whole "aaa.bbb.ccc" string instead of a sub-string

• Status: UNCONFIRMED
• Component: DOM

[Marc Bonnier]

With the following text in a field "aaa.bbb.ccc", double-clicking on "bbb" select the whole "aaa.bbb.ccc" string instead of "bbb". In Firefox and Chrome, only "bbb" is selected while triple-clicking selects the whole string.

It would be nice to have the same "useful" behavior in Safari.

Thanks.

[Alexey Proskuryakov]

This behavior matches Mac platform conventions (TextEdit works in the same way). I don't know what the rationale for TextEdit behavior is.

[Darin Adler]

The title of this bug makes it sound more general than it is. Double clicking selects a word, not the entire contents of a text field. And Mac OS X uses the Unicode standard’s definition of word boundaries.

The Unicode word breaking algorithm says that a.b.c is a single word. The in-word periods are considered part of the word and it is one word. End of sentence periods are different and are not part of the word. The Safari address field uses an alternate algorithm that is better for URLs, whereas the Safari search field uses the standard double-clicking algorithm that is better for English-language test.

I think that programmers and other technical expert are doing to like the idea of a simpler word algorithm than the Unicode one; one that always treats periods as word boundaries, even when they are not end-of-sentence periods. I believe that kind of simpler algorithm is what the other browsers are using.

For fields with URLs in them or email addresses, the simpler algorithm would probably be better.

When testing this in Safari I discovered that if you double-click on the period in "a.b.c" only the period is selected. This is *not* consistent with the Mac OS X platform behavior or the Unicode algorithm and deserves a separate bug report.

[Darin Adler]

Alexey pointed out something and we did a bit of research:

    1) The initial double click uses a different code path than extending the selection does. They should use the same code path.

    2) The initial double click code path treats these characters inside otherwise-alphabetical words as part of a single word. The selection extending code does not.

    3) The Unicode Text Segmentation document has the following to say about this:

    'To allow acronyms like “U.S.A.”, a tailoring may include U+002E full stop in ExtendNumLet.'

Our current guess is that the initial double click code path ends up using the word algorithm with a tailoring that includes the full stop character (period) in this fashion.