Repository navigation
selectionStart/selectionEnd behavior needs to be specified #2424
Description
Right now the spec is pretty much silent on how this stuff works, and as a result browsers have all sorts of behavior differences, both internally and across browsers. Some examples:
-
In Chrome,
var x = document.createElement(tag); x.defaultValue = "abc"; alert(x.selectionStart);will alert 0 iftagis"input"but 3 iftagis"textarea". -
In Safari,
var x = document.createElement("textarea"); x.defaultValue = "abc"; alert(x.selectionStart);alerts 0. So dovar x = document.createElement("textarea"); document.body.appendChild(x); x.defaultValue = "abc"; alert(x.selectionStart);andvar x = document.createElement("textarea"); x.selectionStart = x.selectionStart; x.defaultValue = "abc"; alert(x.selectionStart);. Butvar x = document.createElement("textarea"); document.body.appendChild(x); x.selectionStart = x.selectionStart; x.defaultValue = "abc"; alert(x.selectionStart);alerts 3. -
In Gecko... there are various inconsistencies, esp between textarea vs input, display:none vs non-display-none, etc. I'm fixing some of this stuff right now, so not sure it's worth going into the details, which are changing.
OK, what does the spec actually say? It says that setting the "value" IDL attribute of an input that is in "value" mode will move the text entry cursor (if there is one!) to the end of the text.
It also says that setting the "value" IDL attribute of textarea should do the same thing.
It says that UAs must "follow platform conventions to determine their initial state" for the text entry cursor and selection.
That's it. There's no indication of how this initial state should get modified when the value or default value changes...
Activity
bzbarsky commentedon Mar 8, 2017
So here is a proposal for specific behavior:
The initial state of the text entry cursor is at the beginning of the text control. The web depends on this behavior, looks like; see https://bugzilla.mozilla.org/show_bug.cgi?id=1337392
Setting
.valuemoves the text entry cursor to the end.Anything else that modifies a value just ensures that the text entry cursor is at some position in the range [0, newlength], clamping it to end as needed.
This is what I tentatively plan to implement in Gecko.
bzbarsky commentedon Mar 8, 2017
@cdumez @domenic @travisleithead
Note that I haven't had a chance to test Edge, so maybe it's got sane behavior....
domenic commentedon Mar 8, 2017
/cc @tkent-google
To be clear, this means leaving the text entry cursor alone, unless it would be outside the [0, newlength] range, in which case it gets clamped?
bzbarsky commentedon Mar 8, 2017
Yes, exactly. Probably the same thing for selection too.
So basically, adjust selectionStart/selectionEnd to min(currentValue,newLength).
bzbarsky commentedon Mar 8, 2017
One other problem: it's not clear to me what should happen when the control is focused, or maybe "has been focused". In that case, setting defaultValue seems to put the cursor at the end of the value in browsers? Not sure which parts here are interoperable, exactly.
tkent-google commentedon Mar 9, 2017
I recently filed related issues:
#2411
#2412
This behavior is definitely a bug. Chrome doesn't update selection values for input/defaultValue change at all.
selectionStartandselectionEndcan be out of range. Oops.I agree if this is already interoperable.
Agree. This is defined and interoperable.
I think in many cases modifying a value sets the cursor at the end of the text. At least updating textarea/@DefaultValue sets it to the end in all major browsers.
bzbarsky commentedon Mar 9, 2017
It's complicated. In particular there's ok interop for text controls that come from the parser, I think. But if you try to create one from script, you have to do the equivalent of setting .defaultValue, and suddenly implementations are all over the map per above.
Though #2412 is proposing changing it a bit, right?
Right, setting .value needs to do that per current spec. The question is about value changes that don't set .value but do change the value it returns.
Most obviously, modifying the value via setRangeText or the user typing or whatnot obviously don't move the cursor. It's not clear how .defaultValue sets should behave. What about reset() calls? Direct mutations to the .nodeValue of a child of a textarea? Might be worth testing what UAs do in practice...
That's only sometimes true in Firefox. I'm pretty sure it's false if the textarea is display:none, for example, or not attached to a document...
It's definitely false in Safari, unless I messed something up testing. See my first comment in this issue.
bzbarsky commentedon Mar 9, 2017
As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1345293#c0 this is not necessarily true even in Chrome, depending on what "updating" means....
bzbarsky commentedon Mar 13, 2017
Once this is sorted out, should update the tests in https://hg.mozilla.org/mozilla-central/file/7b19a6386225/testing/web-platform/mozilla/tests/html/semantics/forms/textfieldselection/selection-value-interactions.html and move them to the shared wpt bits.
domenic commentedon Mar 14, 2017
I've posted #2437 and web-platform-tests/wpt#5147 around the first of these bugs, #2412, as that seems rather separable. But this and #2411 seem worth solving together; #2411 is largely a subset of the larger question posed here about what happens if the underlying value is changed, somehow.
@bzbarsky's plan in #2424 (comment) still seems sound as a way forward, modulo the change in #2437 to not set selection to the end if the value is the same. However the big question for me is how to spec it. We could either have something vague, like "whenever the value changes, run these steps", or we could try to find all the places that update the value. We'll need to do the latter for tests anyway. So far what I've got are:
I guess from this perspective a vague "whenever the value changes" makes more sense.
For textareas, there's also a difference between changing the element's value and its raw value. It seems like we only care about changes to value; e.g. if you set the raw value to
"hell\r\no", then set it to"hell\no", that should not change selection. That's the assumption I made in #2437 at least.bzbarsky commentedon Mar 15, 2017
You missed a few. Off the top of my head:
You'd think some of these would be covered by your list, but at least Blink has different behavior for
foo.innerHTML = "<input value='something'>"andvar i = document.createElement("input"); i.setAttribute("value", "something"); foo.appendChild(i);: the former puts the cursor at the start, and the latter puts it at the end...Right. I'm not sure how these interact with selection in practice. Is the selection in the raw value or in the value?
bzbarsky commentedon Mar 15, 2017
Oh, and I think it's obvious that paste/cut should probably not modify selection/cursor stuff in any ways other than the obvious one.... But at this point it would merely sadden me, not surprise me, to discover that we have no interop there either...
domenic commentedon Mar 15, 2017
Sounds good. I'll try to add those to the test cases.
I imagine it should be on something with normalized line breaks (so value or API value) since you can't select the
\rpart of\r\n. I guess API value is the best fit there, hmm. But for determining changes either version with normalized line breaks works, see comment thread at #2437 (comment)32 remaining items
servo: Merge #20051 - Disallow mutating the internals of TextInput (f…
emanchado commentedon Feb 27, 2018
Ok, see different approach in the branch
selection-and-cursor-processing-input-textarea(commit 852ec69). Sorry for the delay, I've been busy.It's obviously incomplete, but I seem to be getting better results:
defaultValue) behave differently in Firefox and Chrome.colortype switching test fails in both (in different ways, too). I wonder if this has defined behaviour and/or it's important.Comments welcome. If this looks good now, I'll keep going and will try to cover all the mentioned cases.
Disallow mutating the internals of TextInput
Change textarea's relevant value to its API value
Clamp selection and text entry cursor position on value changes
Change textarea's relevant value to its API value
Require text entry cursor at the beginning of controls initially
Change textarea's relevant value to its API value
Clamp selection and text entry cursor position on value changes
servo: Merge #20051 - Disallow mutating the internals of TextInput (f…
servo: Merge #20051 - Disallow mutating the internals of TextInput (f…
servo: Merge #20051 - Disallow mutating the internals of TextInput (f…
servo: Merge #20051 - Disallow mutating the internals of TextInput (f…
Clamp selection and text entry cursor position on value changes