Changing the selection creates a Range object

[rniwa]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15470

Anne 2012-01-09 14:59:07 UTC
Make it explicit that once the user changes the selection a Range object is created and associated with the selection.
Comment 1 Aryeh Gregor 2012-01-10 21:15:47 UTC
Browsers seem to differ here. Tested: IE9, Firefox 12.0a1, Chrome 17 dev, Opera Next 12.00 alpha.

Initial range: In IE, Chrome, and Opera, getSelection().rangeCount is initially 0. In Firefox, it's initially 1, with the range collapsed at (document, 0) like with all new ranges.

When the user changes the selection: All browsers replace the existing range with a new one (they don't mutate the old one).

When the user clicks somewhere without dragging, so the selection/cursor disappear: Opera sets rangeCount to 0. Firefox and Chrome make the selection's range collapse at the indicated place. IE make the range collapse to the indicated place if you actually click on some text, but sets rangeCount back to 0 if you click on empty space.

Conclusion: Firefox's behavior is simplest, because it means that if no one calls removeRange/removeAllRanges, rangeCount is always 1, and getRangeAt(0) never throws.

I wonder if we could get away with making removeRange/removeAllRanges actually reset the range to (document, 0)? Or maybe even (document.documentElement, 0)? That would be a significant additional simplification for authors -- then rangeCount is always 1. remove(All)Range(s) followed by addRange would still work as expected. Hmm . . .

More complicated than I expected! (Which just shows that I'm unreasonably optimistic, I guess.) I'll send out a mail and update the spec tomorrow.
Comment 2 Aryeh Gregor 2012-01-11 17:12:49 UTC
I clarified behavior requirements for how to associate ranges with selections, matching Firefox as noted in comment 1: http://dvcs.w3.org/hg/editing/rev/c989dd9e441d

Started a discussion for possible further change: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0107.html
Comment 3 Aryeh Gregor 2012-01-11 19:35:25 UTC
(In reply to comment #1)

Initial range: In IE, Chrome, and Opera, getSelection().rangeCount is initially
0. In Firefox, it's initially 1, with the range collapsed at (document, 0)
like with all new ranges.

This turned out to be wrong. Actually, all browsers start rangeCount as 0. However, I was testing in Live DOM Viewer, and the range wasn't removed when the iframe got unloaded. IE9 and Opera Next 12.00 alpha do appear to remove the range on unload, which is what I'd expect; Firefox 12.0a1 and Chrome 17 dev do not. I fixed the spec so the range is initially null (matching all browsers), and specified the IE/Opera behavior for unload (with a test):

http://dvcs.w3.org/hg/editing/rev/6aaa4b8455c9
Comment 4 Ben Peters 2014-04-21 21:07:29 UTC
Moving to Selection API component.
Comment 5 Ryosuke Niwa 2014-09-16 01:20:54 UTC
Reopening the bug per https://bugzilla.mozilla.org/show_bug.cgi?id=671152

[rniwa]

All major browsers (Blink, Gecko, & WebKit) now agree that when the user clicks on a new element, new Range is created.