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.

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!

(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?

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.

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.

That's a general principle these days (that originated in HTML): https://w3ctag.github.io/design-principles/#priority-of-constituencies.

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.

There is a problem is, I feel that editing API is designed from point of view of authors...