[w3c/uievents] Rationale for "untrusted events do not trigger default actions" (#160)

I'd like to question the specification on this point: untrusted events triggering default actions is the only way, given current JavaScript, to handle events asynchronously while still permitting some events to invoke default behavior. The "alternative" is to emulate all events, which is cumbersome, error-prone (unavoidably so in the case of user-specific keybindings), and an accessibility nightmare.

With default actions triggered by untrusted events, the matter is simple: call preventDefault synchronously on all events, then run the (asynchronous) event handler and let it decide whether to replay the event, by copying the event data to an untrusted event and dispatching that, or to handle the event itself (not doing anything since preventDefault has already been called). 

This used to work.

In essence, we can turn the event handler into an async function with the sole caveat that we need to filter out "trusted" actions synchronously—which makes sense, as malicious code should not be able to delay such actions.

In my application, I would like to support type-ahead as well as on-demand loading of keybindings: the decision whether an event is handled by the keybindings or left to the default action should usually be made instantaneously, but if there is a delay because the (altered) keybindings haven't yet been loaded, that should not affect the outcome of the calculation.

I think dispatching an untrusted event that is then not canceled is the obvious way to invoke its default behavior, to the extent that Web content should be allowed to do so. There is no security argument for requiring JavaScript to manipulate, say, a textarea directly rather than allowing it to dispatch untrusted events (whether or not those correspond to previously-canceled trusted events) to modify it. There is, however, a correctness argument against it: without precise knowledge of the user's keybindings, it's impossible to know what, say, Ctrl-A should be interpreted to mean.

Even if it weren't for that problem, the fact remains that duplicating the complete editing environment is very complex, requiring hundreds of lines of JavaScript code; by contrast, at least in Firefox, ignoring untrusted events was essentially a one-line change.

If it's too late to revisit this decision, or there are indeed good arguments for it that I'm unaware of, I would like to request that at least an API be added to JavaScript to allow replaying untrusted events (again, to the extent that Web content should be allowed to do so).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/160