Implement DOM selections

[jdm]

I propose that we store the bounds of our selection in Document using a starting node, an ending node, a starting offset, and an ending offset. Additionally, we should store a vector of these to enable multiple simultaneous selections in the future, and send all of this data along with each script-initiated reflow request. When a node is part of a selection, it should have a flag set on it (c.f. NodeFlags); when a node with this flag is encountered, the layout code should check whether it's the starting or ending node; if it is not, we can go ahead and style the node entirely as selected. If it is, we need to deal with styling the node content in up to three separate parts (pre-selection, in selection, post-selection).

cc @aweinstock314

[nox]

What if we use a DOM range for the selection boundaries?

[jdm]

Seems reasonable at first glance.

[jdm]

#4409 is related and I can never find it.

[jdm]

@iamrohit7 If you're interested in trying this, I will do my best to advise you!

[ghost]

@jdm Thanks. I'll get back to you with questions.

[pshaughn]

WPT custom-elements/reactions/Selection needs this.

[pshaughn]

Most failures under dom/ranges are also this.

[pshaughn]

Would implement DOM selections, up to a point that satisfies non-webdriver automated tests, be a productive thing to do in itself? I imagine they're not very useful without also having a UI to select things, but on the other hand that UI might be easier to write as its own piece on top of the already-working DOM part.

[jdm]

That would be a useful starting point, indeed.

[pshaughn]

Here's my understanding of what https://w3c.github.io/selection-api/ tells us to do.

Section 2:

• This is mostly preamble but it points out that Document.open resets the selection when it resets the document, which isn't spelled out anywhere in the meatier sections. [however, WPT tests aren't treating this mention as normative]

Section 3:

• Selection is a new DOM object, which can have references to a range and a couple nodes.
• It has many methods that modify or test the range; these are the bulk of the new code to add, but most of them are straightforward.
• It can return a live reference to the range and be affected by subsequent changes to it.

Section 4:

• Document holds a reference to a selection, which is populated with an empty selection when the document's created. [empty as in no-range, not as in length-0-range]
• Document.getSelection returns the selection (by reference) if there's a browsing context for the document, or null if not.
• Window.getSelection calls Document.getSelection.
• onselectstart and onselectionchange get added to the global event handlers (XRSession also uses the word onselectstart, but doesn't use a global event mixin so won't collide)

Section 5:

• When the existing selection is empty or collapsed, a selection UI action (e.g. drag) fires a selectstart event at the node the attempted new selection is starting on, and if this event is cancelled the selection isn't made. This is the only part of the spec that prescribes any UI functionality.
• Whenever the selection's range changes either by UI action or script, whether by setting a new range, discarding the existing range, or even a mutation to the existing range, a non-cancelable selectionchange event is fired at the document.

Could someone else give it a skim and let me know if there's anything I've left out here?

[pshaughn]

The selectionchange event has no tests and some underspecification (w3c/selection-api#117) but I'll try to make some version of it work. Aside from that, I have a build that seems to be otherwise working, passing WPT tests that incidentally use getSelection, but I'm also getting some unexpected harness timeouts and I don't know how they relate to my changes yet. I'll push a draft of whatever I've got today, hopefully in a state where someone else could pick up the UI part.

[jdm]

In response to your task source question, 7b3cf27#diff-a1afe92a339a20989be95f03c80740e5 is a nice example of adding a new task source. That being said, the DOM manipulation task source is generally a safe choice when a spec doesn't explicitly state one.

[pshaughn]

The next big step here is figuring out how to convert a click into a range boundary, in the general case where we don't know in advance if it's going to be counting characters or counting child nodes.