Fix selection/text entry cursor position processing for input/textarea #3472

domenic · 2018-02-17T00:16:52Z

This is mainly aimed at fixing #2424. I split it up into three commits: the first is editorial to give concepts some definitions and make them easier to work with; the second fixes a bug in a related area; and the last one contains the important clamping changes discussed there.

Feel free to review only the last two diffs, or only the last one.

/cc @bzbarsky @tkent-google @jonleighton @jdm @emanchado as people involved in the various threads related to this issue.

As discussed in #2424 (comment), I need help writing the web platform tests for this. Also, probably someone should port the example in the spec that I added (for distinguishing raw value vs. API value) to another WPT.

/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/input.html ( diff )

jonleighton · 2018-02-17T19:45:04Z

Thanks for getting this started. The changes you've made so far make sense to me but per my comment in #3468, I personally think it would make better logical sense for the reset algorithm to set the text entry cursor to the beginning of the text control, remove any selection, and set the selection direction to "none". When the reset algorithm is invoked, the user wants to return the control to its initial state, so IMO it doesn't make sense to retain the existing cursor / selection bounds (which might even relate to a different pre-reset value).

domenic · 2018-02-17T20:54:24Z

I understand that position, but I don't think we should be inventing new behavior for the reset algorithm; I'd rather it behave the same as other value changes.

tkent-google

lgtm

bzbarsky · 2018-02-21T02:46:11Z

The proposed changes look ok to me.

These tests already show differences between eg. Firefox and Chrome, and show what seems to be browser bugs. Follows whatwg/html#3472.

annevk

Some of the longer conditionals would also be clearer with "then" added, but since this is three commits I didn't go in and make that change.

annevk · 2018-03-15T10:04:24Z

source

-   data-x="">none</code>".</p></li>
+   element's <span data-x="concept-textarea/input-cursor">text entry cursor position</span> to the
+   beginning of the text control, and <span data-x="set the selection direction">set its selection
+   direction</span> to "<code data-x="">none</code>".</p></li>


Why is there a comma before "and" here? Because it's a slightly longer sentence?

Yeah, I guess so. I think without it you might start reading things as "Set the element's text entry cursor position to the (beginning of the text control and X)" before you realize that X is a verb phrase so you have to switch your reading to "(Set the element's text entry cursor position to the beginning of the text control) and (X)".

annevk · 2018-03-15T10:05:54Z

source

+  <dfn data-x="concept-textarea/input-selection">selection</dfn> or a <dfn
+  data-x="concept-textarea/input-cursor">text entry cursor position</dfn> at all times (even for
+  elements that are not <span>being rendered</span>). The initial state must consist of a <span
+  data-x="concept-textarea/input-cursor">text entry cursor</span> at the beginning of the control.</p>


Why is a position not a collapsed selection?

I don't know. That would be a pretty invasive change to make, and I'm not sure of all the implications, given all the other places in the spec that depend on this dual concept. Could be investigated as a follow-up, I suppose.

Part of the answer may lie in this (preexisting) clause: "If the user agent does not support empty selection".

It just seems weird to me since that's how Selection objects work. (That doesn't seem to allow user agents to not support that either.)

annevk · 2018-03-15T10:06:27Z

source

+  <div class="example">
+   <p>The use of <span data-x="concept-fe-api-value">API value</span> instead of <span
+   data-x="concept-textarea-raw-value">raw value</span> for <code>textarea</code> elements means
+   that U+00D (CR) characters are normalized away. For example,


Fixed, thanks!

This gives explicit definitions to the concepts of "selection", "text entry cursor position", and "relevant value" for selection/cursor purposes.

Per the test case included as an example in the spec, this is more in line with browser behavior, and makes more sense. A similar conclusion was reached on related matters in #2424, and also in #2437.

Fixes #2424. Fixes #2411. Fixes #3468.

annevk

I'll approve since editorially it's fine and bz said it was fine (presumably for the non-editorial stuff).

It doesn't make sense to me though that we use a fundamentally different model here from the rest of the tree, even though this supposedly happens in user agent shadow trees. Let's file a follow-up?

domenic · 2018-03-16T09:20:03Z

I'm not sure shadow trees are related, but sure.

annevk · 2018-03-16T09:21:27Z

@domenic isn't the idea model that <textarea> is just <div contenteditable> with some restrictions hidden via a shadow tree? I thought that's even how it's implemented in some engines.

domenic · 2018-03-16T09:22:06Z

If so, I was not aware. E.g. you cannot bold the contents of a textarea. It seems more like input than contenteditable to me.

domenic · 2018-03-16T09:30:21Z

Browser bugs:

I don't have a Mac handy, so if someone could test Safari Tech Preview against http://w3c-test.org/html/semantics/forms/textfieldselection/selection-start-end-extra.html and file a bug if they fail, I'd much appreciated it.

annevk · 2018-03-16T09:32:59Z

https://bugs.webkit.org/show_bug.cgi?id=183692

…ge selection update, a=testonly Automatic update from web-platform-testsAdd first batch of tests for selection update These tests already show differences between eg. Firefox and Chrome, and show what seems to be browser bugs. Follows whatwg/html#3472. wpt-commits: 05d6e35a439546add8dc619c4641ae83551249f8 wpt-pr: 9799 wpt-commits: 05d6e35a439546add8dc619c4641ae83551249f8 wpt-pr: 9799

…ge selection update, a=testonly Automatic update from web-platform-testsAdd first batch of tests for selection update These tests already show differences between eg. Firefox and Chrome, and show what seems to be browser bugs. Follows whatwg/html#3472. wpt-commits: 05d6e35a439546add8dc619c4641ae83551249f8 wpt-pr: 9799 wpt-commits: 05d6e35a439546add8dc619c4641ae83551249f8 wpt-pr: 9799 UltraBlame original commit: ab846aeed267cce05d8f796111c0f70d6a01c4a7

domenic added topic: forms needs tests Moving the issue forward requires someone to write tests labels Feb 17, 2018

jonleighton mentioned this pull request Feb 20, 2018

More readable code and major fixes for form reset servo/servo#20069

Closed

4 tasks

tkent-google reviewed Feb 21, 2018

View reviewed changes

domenic pushed a commit to web-platform-tests/wpt that referenced this pull request Mar 6, 2018

Add first batch of tests for selection update

05d6e35

These tests already show differences between eg. Firefox and Chrome, and show what seems to be browser bugs. Follows whatwg/html#3472.

domenic removed the needs tests Moving the issue forward requires someone to write tests label Mar 15, 2018

annevk reviewed Mar 15, 2018

View reviewed changes

domenic added 3 commits March 16, 2018 15:32

Editorial: clarify some text selection/cursor concepts

8f69421

This gives explicit definitions to the concepts of "selection", "text entry cursor position", and "relevant value" for selection/cursor purposes.

Change textarea's relevant value to its API value

0b9ee5d

Per the test case included as an example in the spec, this is more in line with browser behavior, and makes more sense. A similar conclusion was reached on related matters in #2424, and also in #2437.

Clamp selection and text entry cursor position on value changes

8baa46b

Fixes #2424. Fixes #2411. Fixes #3468.

domenic force-pushed the selection-start-end-again branch from 700d1a8 to 8baa46b Compare March 16, 2018 06:34

annevk approved these changes Mar 16, 2018

View reviewed changes

domenic merged commit 3d2719a into master Mar 16, 2018

domenic deleted the selection-start-end-again branch March 16, 2018 09:20

domenic mentioned this pull request Mar 16, 2018

Is there a meaningful distinction between having a text entry cursor position and an empty selection? #3574

Open

jdm mentioned this pull request Mar 17, 2018

Update text cursor handling to match spec servo/servo#20322

Open

domenic mentioned this pull request Jan 11, 2020

jsdom does not update selectionStart when value of <input type=text> is set jsdom/jsdom#2787

Closed

Matthew-Goldberg mentioned this pull request Jan 16, 2020

Selection set to end on input value change jsdom/jsdom#2799

Merged

zcorpan mentioned this pull request Mar 15, 2023

Clarify selection behaviour of setting textarea value via property #9028

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix selection/text entry cursor position processing for input/textarea #3472

Fix selection/text entry cursor position processing for input/textarea #3472

domenic commented Feb 17, 2018 •

edited by pr-preview bot

Loading

jonleighton commented Feb 17, 2018

domenic commented Feb 17, 2018

tkent-google left a comment

bzbarsky commented Feb 21, 2018

annevk left a comment

annevk Mar 15, 2018

domenic Mar 16, 2018

annevk Mar 15, 2018

domenic Mar 16, 2018 •

edited

Loading

domenic Mar 16, 2018

annevk Mar 16, 2018

annevk Mar 15, 2018

domenic Mar 16, 2018

annevk left a comment

domenic commented Mar 16, 2018

annevk commented Mar 16, 2018

domenic commented Mar 16, 2018

domenic commented Mar 16, 2018

annevk commented Mar 16, 2018

Fix selection/text entry cursor position processing for input/textarea #3472

Fix selection/text entry cursor position processing for input/textarea #3472

Conversation

domenic commented Feb 17, 2018 • edited by pr-preview bot Loading

jonleighton commented Feb 17, 2018

domenic commented Feb 17, 2018

tkent-google left a comment

Choose a reason for hiding this comment

bzbarsky commented Feb 21, 2018

annevk left a comment

Choose a reason for hiding this comment

annevk Mar 15, 2018

Choose a reason for hiding this comment

domenic Mar 16, 2018

Choose a reason for hiding this comment

annevk Mar 15, 2018

Choose a reason for hiding this comment

domenic Mar 16, 2018 • edited Loading

Choose a reason for hiding this comment

domenic Mar 16, 2018

Choose a reason for hiding this comment

annevk Mar 16, 2018

Choose a reason for hiding this comment

annevk Mar 15, 2018

Choose a reason for hiding this comment

domenic Mar 16, 2018

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

domenic commented Mar 16, 2018

annevk commented Mar 16, 2018

domenic commented Mar 16, 2018

domenic commented Mar 16, 2018

annevk commented Mar 16, 2018

domenic commented Feb 17, 2018 •

edited by pr-preview bot

Loading

domenic Mar 16, 2018 •

edited

Loading