Activation notification on user input should be triggered from the browser process |
|||||||||
Issue descriptionWhen the user interacts with a page, we trigger user activation notification calls in the renderer process. This is how it works today: the "event-target" renderer updates its local frame tree and sends an IPC to the browser; the browser updates its frame tree and sends IPCs to all other renderers each of which then updates its local frame tree. See FrameTreeNode::user_activation_state_. We need to move the activation triggering to browser process because: - a compromised renderer shouldn't be able to clobber other renderers' states, and - a renderer receives input events from the browser, so the round trip back to the browser is unnecessary and slow. With User Activation v2, we carried the convoluted state update mechanism over from the old UserGestureIndicator-based code for the following reasons: - UAv2 is a fundamental model-change that introduced many regressions, and we wanted to avoid even more regressions through input-event-set changes. - UAv2 gives us a chance to "define" activation-triggering events from scratch, and we wanted to use this opportunity to (propose a) fix for the web which is currently broken (orphan spec, differences between major browsers). - Before the site-isolation urgency, it was logical to defer implementing browser-side states. There are some challenges with this move, see https://docs.google.com/document/d/1XL3vCedkqL65ueaGVD-kfB5RnnrnTaxLc7kmU91oerg/edit?usp=sharing
,
Jun 11 2018
,
Jun 20 2018
,
Jun 20 2018
rbyers@ and I decided had a quick discussion yesterday, where we decided that this bug (blocking shipping UAv2) should better be handled separately from the "activation defining event-set" bug (Issue 826293) which would involve handling regressions in real websites. As for this bug, we will decouple UAv2 from v1 triggering, and "copy" existing event-set in the browser-side. Since token merging is non-existent in UAv2, we may see a bit of regression (say 2 popups per mousedown-mouseup event sequence) but we believe it's not gonna be terrible.
,
Aug 14
,
Oct 1
,
Oct 1
We want to fix this bug to safeguard against an untrusted renderer process. We shouldn't block UAv2 core changes on this.
,
Oct 11
,
Nov 14
Sounds like this may be important for Site Isolation guarantees against compromised renderers. What's the next step for this? Are there things we should do on the Site Isolation side? Thanks!
,
Nov 14
,
Nov 15
We only did some initial planning so far, expecting to start the work in Q1 after UAv2 ships this quarter. To set the expectations right, we don't see a quick way forward because this most likely would break web-sites in non-trivial way. It's not easy to predict the impact because: - Involves all activation-gated APIs, most notably popup-blocker. - A big fraction of current activation notification calls in renderer are not even triggered by user input, to make them functional with old (UAv1) model. After UAv2 ships, theoretically they are ready to be replaced but we still have to look into each case one by one. We tentatively planned to move the non-synthetic activation calls first, in an incremental manner, say by event type (mouse then keyboard etc). Then we would look into the synthetic activation calls. This would let us parallelize the work (and isolate possible roll-backs). --- Now that this bug is blocking Issue 786673, when do you expect to resolve that issue?
,
Dec 3
,
Dec 3
> Now that this bug is blocking Issue 786673, when do you expect to resolve that issue? We're trying to get the highest priority enforcements landed in Q1 2019. User activation may not be as critical as some of the other enforcements (apart from cases where there's a privileged page involved, like chrome://downloads), so it may be ok if this isn't complete in the same time frame. Still, it does seem like any features gating actions on user activation would benefit from not being tricked by a compromised renderer process, so we should continue to pursue this. Thanks!
,
Jan 14
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by mustaq@chromium.org
, Jun 1 2018Blocking: 696617