search

w3c / selection-api

Selection API
http://w3c.github.io/selection-api/
Other
47 stars 30 forks source link

Clarify how text selection in <input> and <textarea> work with Selection interface #83

Open tkent-google opened 7 years ago

tkent-google commented 7 years ago

The relationship between Selection interface and text control selections is unclear. Let's clarify, and ask for updating HTML specification if needed.

rniwa commented 7 years ago

The biggest difference between WebKit/Blink and Gecko is that the former two will update the selection inside a text field based on APIs on Selection whereas Gecko doesn't.

tkent-google commented 7 years ago 
<!DOCTYPE html>
<body><div></div><input value="initial"><div></div>
<script>
var sel = getSelection();
sel.removeAllRanges();
var i = document.querySelector('input');
i.setSelectionRange(1, 1);
alert('before focus: ' + sel.anchorNode + ' ' + sel.anchorOffset +
  ' ' + sel.focusNode + ' ' + sel.focusOffset);

i.focus();
alert('after focus: ' + sel.anchorNode + ' ' + sel.anchorOffset +
  ' ' + sel.focusNode + ' ' + sel.focusOffset);
</script>
</div>
  Firefox Chrome Safari Edge
before focus null 0 null 0 null 0 null 0 body 1 body 1 body 1 body 1
after focus body 1 body 1 body 1 body 1 body 1 body 1 body 1 body 1

It seems a difference is only how text control selection API works without focus.

tkent-google commented 7 years ago

As for Selection.toString(), Chrome and Safari return selected string in a text control, and Edge and Firefox returns nothing.

andreubotella commented 2 years ago

I was testing the selection range with input and textarea, and there is also a difference between Blink/WebKit and Gecko. If some text in a text field or textarea is selected, the selection range in Blink and WebKit seems to be equivalent to a caret selection immediately before the input or textarea (so range.startContainer === input.parentNode). Gecko's behavior is much stranger: it seems like if the last non-text-field selection was a range selection, it treats the new selection as empty; but if the last non-text-field selection was a caret selection, it keeps it.

Gecko's behavior is almost certainly unintentional and the result of an implementation bug, but I wonder whether Blink/WebKit's behavior is worth keeping.