search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
615 stars 69 forks source link

isInputPending API #155

Open tantek opened 5 years ago

tantek commented 5 years ago

Request for Mozilla Position on an Emerging Web Specification

Other information

Filing because it got some prominence in tech press and we should consider a summary position, especially to state concerns.

From my understanding this API is an attempt at providing web developers more control to improve user-perceived load-time performance, yet is a "run-to-completion violation".

CC: @smaug----

Label: WICG

(Originally published at: https://tantek.com/2019/116/b1/request-position-isinputpending)

smaug---- commented 5 years ago

The main issue with the proposal is that it is super high level. It doesn't define which events are handled. For instance the example in the explainer uses 'click', but that isn't a user input event - 'click' is generated by browser based on mousedown/up.

Explainer does talk about security, but since the API let's one to check which event is pending, other pending events before such event may move focus or move the location of iframes.

Please check also https://github.com/WICG/is-input-pending/issues

I do feel like the API does reveal useful information to the web pages, but in its current form it feels rather scary.

CYBAI commented 5 years ago

@smaug---- maybe you want to refer https://github.com/WICG/is-input-pending/issues/11 👀?

smaug---- commented 5 years ago

Well, all the issues there are. But currently there isn't any specification so it is really hard to say how the API should behave.

acomminos commented 3 years ago

Friendly ping on this issue. The API now has a spec, and the concerns about user input event types should be resolved by having moved to a model of continuous/discrete input events agnostic of DOM events.

smaug---- commented 3 years ago

Looks like the model in the spec isn't quite right, given that any JS running task may dispatch UI events. But those issues should be fixable. But the spec does seem to rely on some events being lost, especially when it comes to key events. Focus may always change before key event is dispatched, and that should cause event to go to some other place, possibly to cross-origin page. That feels possibly scary behavior. @acomminos have you considered if some attacks could be done by moving focus, assuming that UA works correctly and doesn't drop event key events?

smaug---- commented 3 years ago

I guess per proposal UA could always return true from isInputPending() "if the user agent determines that it might soon enqueue such a task" and that could be used for problematic cases. But that feels still a hack.

acomminos commented 3 years ago

Thanks @smaug----. That's correct, one of the ideas motivating that clause was for situations like you mention, where you might want to clear enqueued events on a focus change to avoid misattribution (but would still have to return true for isInputPending, since we can't predict the future).

To avoid hackiness there, would it make sense to provide further non-normative guidance about cases where you might want to do this? Alternatively, we could also refine the clause to only permit false positives in certain cases (like your example) if they're definable and not too numerous.

smaug---- commented 1 year ago

It is still unclear to me what to do with cross-origin iframes if they live in the same process as the parent page. Should isInputPending return always false or always true. Returning always false might lead to bad user experience if the iframe does some heavy calculations and relies on isInputPending to suspend that work, and true might slow that that page if it can't process anything for a long time. Though, it might be other way round too. User interacting with the iframe - what should the top level page's isInputPending return.