Web apps cannot cancel input from Firefox's autocomplete, password manager, etc with `beforeinput` event
Categories
(Core :: DOM: Events, defect, P5)
Tracking
()
People
(Reporter: masayuki, Unassigned)
References
Details
Chrome and Safari do not fire beforeinput event when you use their autocomplete and password manager. However, Input Events define that they should be cancelable.
https://w3c.github.io/input-events/#interface-InputEvent-Attributes
(See insertReplacementText case.)
Therefore, only Gecko conforming to the spec may cause only our users cannot use autocomplete and password manager on some web sites even if they don't expect to cancel the cases. For protecting our users, bug 1607131 made beforeinput event fired in the cases by default, but if Chrome and Safari change their behavior to conforming to the spec, we should follow it at least in the default settings.
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
Note sure if you saw this in the meeting chat, but please file an issue against the specification as well to track this discrepancy. Thanks!
|
|
Reporter | |
Comment 2•4 years ago
|
||
(In reply to Anne (:annevk) from comment #1)
Note sure if you saw this in the meeting chat, but please file an issue against the specification as well to track this discrepancy. Thanks!
Well, I don't think that this is a bug of the spec. I believe that it's reasonable to cancel autocomplete input and password manager input with beforeinput events since web apps developers may want to ban them on their form (although I don't like such site). And there is another insertReplacementText input type, that is word correction with builtin spellchecker. In this case, all browsers dispatch a cancelable beforeinput event. So, I think that it's hard to say that the spec define it as non-cancelable...
Or do you think that I should file a spec issue as different topic? E.g., split the inputType value from spellchecker?
|
|
||
Comment 3•4 years ago
|
||
If you expect this to be resolved quickly I suspect it does not need an issue, but given that we had to implement special behavior already it seems worth tracking on the specification side, also to ensure it will get test coverage.
|
||
Comment 4•4 years ago
|
||
I believe that it's reasonable to cancel autocomplete input and password manager input with beforeinput events since web apps developers may want to ban them on their form (although I don't like such site).
Well, that seems like intentional sabotage of an important web browser feature to me. Allowing that doesn't seem reasonable to me.
A browser's primary customer is its user, not web developers. We should always (100%) consider what is best for the user as the highest priority. Web developers needs and wishes have lower priority. (I'm aware that this isn't governed by a CSS spec, but fwiw, for CSS features the hierarchy is "user > author > UA > spec editor".)
We shouldn't allow web developers to break important browser features just because a spec says so. If that's the case here, then we should change the spec. Especially if Chrome and Safari already isn't following the spec.
|
|
||
Comment 5•4 years ago
•
|
||
That's a general principle these days (that originated in HTML): https://w3ctag.github.io/design-principles/#priority-of-constituencies.
|
|
||
Comment 6•4 years ago
|
||
Thanks, that is indeed the design principle I was alluding to. Thanks for linking to the precise wording. It's good to know that's a shared value in the wider web-platform community.
|
|
Reporter | |
Comment 7•4 years ago
|
||
There is a problem is, I feel that editing API is designed from point of view of authors...
|
||
Comment 8•2 months ago
|
||
I don't see what value there is in not triggering beforeinput events when password managers and similar tools are used. It simply means that the values will not be read by several web applications that rely on catching user input by means of beforeinput events. I don't see any advantages in terms of privacy either. It's not difficult at all to read out the password set by the password manager or to change the value to something else (which would be the same as cancelling the beforeinput event and then changing the input to something else. For example with an interval like this:
const passwordInput = document.querySelector('input[type=password]')
let password = passwordInput.value
setInterval(
() => {
if (passwordInput.value !== password) {
console.log(`New password: ${passwordInput.value}`)
passwordInput.value = password
}
},
1000
)
|
|
Reporter | |
Comment 9•2 months ago
|
||
Oh, that's a terrible way... Hmm, if we would get web-compat bug reports on such web apps, we may have needed to stop dispatching beforeinput for such inputs like the other browsers.
Description
•