Text control selections API conformance

[KiChjang]

We currently have WebIDL bindings to the selectionStart, selectionEnd and selectionRange setter functions on the HTMLInputElement, but these setters do not follow the spec completely since they do not fire select events on the input element when they are called.

In addition, we should also check that the code for these setters are matching the steps as outlined in the spec.

Code: components/script/dom/htmlinputelement.rs
Spec: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea%2Finput-selectionstart
Test: tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-start-end.html

EDIT: Since @jonleighton has taken this up and focused their efforts on ensuring conformance of both HTMLInputElement and HTMLTextAreaElement selections API, the scope of this issue has been expanded accordingly.

[highfive]

Hi! If you have any questions regarding this issue, feel free to make a comment here, or ask it in the #servo channel in IRC.

If you intend to work on this issue, then add @highfive: assign me to your comment, and I'll assign this to you. 😄

[tigercosmos]

Did the previous PR solve part of this?

[KiChjang]

No, it did not.

[jonleighton]

Hi, I'd like to have a go at working on this. I've not contributed to servo before so please bear with me...

I've established that the select event is already being fired by setSelectionRange, since that was implemented in f60de52. However it is not fired by the selectionStart or selectionEnd setters.

[jonleighton]

PR submitted for firing the event. Once it is approved I could look into other related issues (e.g. the remaining failing tests, also the spec says that the event should only fire if the selection has actually changed).

[jonleighton]

I think this assertion (and the other related assertions in other tests) is not correct per the spec.

The spec says:

If there is no selection, return the offset (in logical order) to the character that immediately follows the text entry cursor.

Further down, it then says:

All elements to which this API applies have either a selection or a text entry cursor position at all times (even for elements that are not being rendered). The initial state must consist of a text entry cursor at the beginning of the control.

The assertion in the test is checking that the text entry cursor is at the end of the control, however.

I made a quick test to check the behaviour in other browsers. Both Firefox and Chromium print 0 for all values in that test page.

So I think the test needs to change, but I'm just checking to see if I have missed something?

[jonleighton]

Sorry, I'm incorrect because the value is set via JS, therefore step 5 from here applies:

If the element's value (after applying the value sanitization algorithm) is different from oldValue, and the element has a text entry cursor position, move the text entry cursor position to the end of the text control, unselecting any selected text and resetting the selection direction to "none".

[jonleighton]

Latest PR: #19461 (I forgot to ref this issue there)

[jonleighton]

@highfive: assign me

[highfive]

It looks like this has already been assigned to someone. I'll leave the decision to a core contributor.

[jonleighton]

Once #19544 is merged, the only remaining thing that I'm aware of is steps 7-9 of the input type change algorithm. I can't see any existing WPT tests for that so will need to add some I think.

[jonleighton]

Actually, I have just added another commit on that PR which deals with the above, so I think we can close this issue once the PR is merged.

[jonleighton]

@KiChjang this can be closed now!