search

w3c / input-events

Input Events
https://w3c.github.io/input-events/
Other
23 stars 16 forks source link

"insertReplacementText" value is really necessary? #85

Closed masayuki-nakano closed 5 years ago

masayuki-nakano commented 5 years ago

It was added by https://github.com/w3c/input-events/issues/31 so, I'm ccing guys commented in it: @choniong, @johanneswilm, @alexelias

Currently, some web sites hate password manager, autocomplete, etc which helps user to input complicated and/or meaningless word(s). If browser sets inputReplacementText, its beforeinput events may be banned by such web apps. Then, users cannot use password manager, that means users need to use simple and easy password to remember.

So, it might be better to remove inputReplacementText if it's not useful for web apps. What's the scenario of web apps using the value?

johanneswilm commented 5 years ago

Hey @masayuki-nakano, The main point of the spec is to make it possible to create richtext editors. For this it is essential that all input types are covered. That's why over the past four years through a number of meetings and many discussions on the email list, we developed the spec as we did. Web editors need to know the semantic meaning of any type of input.

What you seem to be describing is a usecase in an input field (?), which we mainly cover for the purpose of consistency, but it's not the principal purpose of this spec. Further, you seem to be describing a type of battle between web apps and browser in which the browser wants to provide autocomplete password completion, while the (badly programmed) web app wants to prevent for the browser's autocomplete to be used. You are then proposing removing functionality that is essential for richtext editors in order for the browser to save the web app from its own bad programming. Did I understand that correctly?

I guess my answer to that is that a web app can already today without any of this prevent password autofillers to be used - for example by implementing its own password input field or by listing for the number of keyboard input events, and if the input string is longer than what it should be based on what characters were entered it could just reset the password field immediately.

So my answer to this is: no, I think it would not be a good idea to remove insertReplacementText as it is an essential event for the operation of a richtext editor, and removing it does not prevent bad programmers from writing password input fields that cannot be used with autofilling mechanisms anyway, so removing it does not solve the issue you mention (if that is an issue at all).

(btw, I believe @choniong and @alexelias are no longer working on input/editing in Chrome or Android.)

johanneswilm commented 5 years ago

As for why this event is essential (and why the entire spec is important):

Editors currently need to rely on a number of different sources to get all the document changing input the user does. To really get everything, the JS needs to diff the DOM to notice all changes. Yet it is then difficult to understand what the user meant with their change - did the user try to make a specific part bold? Did the user try to merge something? Did the user remove specific text and enter something entirely different? Or did the user just replace one word with another by means of spell checking?

The JS currently has to do a post-mortem analysis to figure out what happened and what the user really tried to do. This analysis will necessarily be imperfect. In order to improve the situation, we have created the input events spec, which should give the user semantic information about the kind of user action the user tried to execute through browser native input controls.

In this specific case, using insertReplacementText is useful because it signals that the text we are entering is replacing some other text that was there before - such as by means of a spell checker. The JS editor may for example decide that in case of such replacement, the selection should not be moved, whereas if the event were insertText, the selection should be moved to the inserted text. I think we had some longer discussions around the need for this at TPAC in 2016.

masayuki-nakano commented 5 years ago

@johanneswilm:

The main point of the spec is to make it possible to create richtext editors. For this it is essential that all input types are covered. That's why over the past four years through a number of meetings and many discussions on the email list, we developed the spec as we did. Web editors need to know the semantic meaning of any type of input.

What you seem to be describing is a usecase in an input field (?), which we mainly cover for the purpose of consistency, but it's not the principal purpose of this spec.

Ah, yes, and it's really good point which I want to get.

Further, you seem to be describing a type of battle between web apps and browser in which the browser wants to provide autocomplete password completion, while the (badly programmed) web app wants to prevent for the browser's autocomplete to be used. You are then proposing removing functionality that is essential for richtext editors in order for the browser to save the web app from its own bad programming. Did I understand that correctly?

Sure.

I guess my answer to that is that a web app can already today without any of this prevent password autofillers to be used - for example by implementing its own password input field or by listing for the number of keyboard input events, and if the input string is longer than what it should be based on what characters were entered it could just reset the password field immediately.

So my answer to this is: no, I think it would not be a good idea to remove insertReplacementText as it is an essential event for the operation of a richtext editor, and removing it does not prevent bad programmers from writing password input fields that cannot be used with autofilling mechanisms anyway, so removing it does not solve the issue you mention (if that is an issue at all).

Big point of beforeinput is, web apps become prevent insertion after browser does something. So, if there is no beforeinput, browser can forcibly insert anything with its own UI. However, beforeinput allows to prevent after user operates something of browser UI. This is really big difference than implementing beforeinput.

In this specific case, using insertReplacementText is useful because it signals that the text we are entering is replacing some other text that was there before - such as by means of a spell checker. The JS editor may for example decide that in case of such replacement, the selection should not be moved, whereas if the event were insertText, the selection should be moved to the inserted text. I think we had some longer discussions around the need for this at TPAC in 2016.

Okay, although I still don't have clear idea what web apps do with insertReplacementText, however, there is the difference between <input> and contenteditable. So, when web browsers need to battle with "bad" login forms, browsers can do something only in <input>. That's really good hint to me, thank you. But any standards need to battle with bad usages...

Anyway, really thank you. I got it. If nobody raise related issue, please ignore this report.

johanneswilm commented 5 years ago

Big point of beforeinput is, web apps become prevent insertion after browser does something. So, if there is no beforeinput, browser can forcibly insert anything with its own UI. However, beforeinput allows to prevent after user operates something of browser UI. This is really big difference than implementing beforeinput.

You can, yes, but if the web app is really "evil", it can implement its own password input field so that the browser does not notice it is a password field and hence will not use offer autofilling. So then the effect is the same.

If you want to protect password fields in some other way, you could turn off all beforeinput/input events for password fields. Even then the web app could simply check the value of the field every 50 ms and then act by deleting all contents if more than one new letter has appeared in the field since the last check.

Okay, although I still don't have clear idea what web apps do with insertReplacementText ...

As I said, you may decide that the selection (caret) should not be moved if text is being replaced. So for example if you have this:

The tetx I am writing.|
| = caret

And the user right-clicks on "tetx" and in the context menu chooses "text" in the spell checker so that we get a beforeinput event with inputType insertReplacementText, you may want to end up with this:

The text I am writing.|

Rather than:

The text| I am writing.

which is what you would likely want is the inputType is insertText.

We had some really long discussions about this at TPAC 2016 and possibly also the mailing list. Maybe it has been archived somewhere.

masayuki-nakano commented 5 years ago

@johanneswilm

Big point of beforeinput is, web apps become prevent insertion after browser does something. So, if there is no beforeinput, browser can forcibly insert anything with its own UI. However, beforeinput allows to prevent after user operates something of browser UI. This is really big difference than implementing beforeinput.

You can, yes, but if the web app is really "evil", it can implement its own password input field so that the browser does not notice it is a password field and hence will not use offer autofilling.

Of course, yes.

So then the effect is the same.

But I doubt this since anyone needs to think cost of implementation.

If you want to protect password fields in some other way, you could turn off all beforeinput/input events for password fields. Even then the web app could simply check the value of the field every 50 ms and then act by deleting all contents if more than one new letter has appeared in the field since the last check.

Yeah, this is probably good solution for login forms. Firefox might have such protection (disabled by default of course).

Okay, although I still don't have clear idea what web apps do with insertReplacementText ...

As I said, you may decide that the selection (caret) should not be moved if text is being replaced. So for example if you have this:

The tetx I am writing.|
| = caret

And the user right-clicks on "tetx" and in the context menu chooses "text" in the spell checker so that we get a beforeinput event with inputType insertReplacementText, you may want to end up with this:

The text I am writing.|

Rather than:

The text| I am writing.

which is what you would likely want is the inputType is insertText.

Thanks, maybe good example.

(And I realize right now, I can close this issue by myself.)