Consider consuming user activation w/o an expiry time |
||||
Issue descriptionIn our proposed Simple User Activation model, one open question is defining the behavior of the transient bit. More precisely, do we want the bit: [A] to expire after a certain time limit, or [B] to get consumed when /any/ user APIs check it, or [C] to get consumed when /some/ user APIs check it? Or to have some combination of A/B/C above? Design doc: https://docs.google.com/document/d/1erpl1yqJlc1pH0QvVVmi1s3WzqQLsEXTLLh6VuYp228/edit?usp=sharing Github issue: https://github.com/whatwg/html/issues/1903 Our current UGI-based system has [C] which seems unpredictable when two different APIs are combined, see Issue 729694 . So the real choice we have is between [A] and [B]. The discussion in the github issue suggests that [A] should be necessary (this seems intuitive but we don't have any data). Perhaps [B] is not important since currently only 3 APIs (popups, WebUSB, WebBluetooth) rely on consumption. Popup is the strongest case here for sure but we need to test if dropping consumption is really that bad. We will first test without [B]. If it doesn't look reasonable, we will see if we need [B] on top of [A] or may be only [B].
,
Nov 1 2017
,
Nov 28 2017
Looks like Safari 11 (tested 11.0.1) has started consuming user activation for popups, which leaves Firefox as the only major browser with no-consumption behavior!
,
Nov 28 2017
We will pivot the goal here to cope with the new reality: we won't try no-consumption at all. Instead we will see if consumption without a time-limit is acceptable. Spec discussion here: https://github.com/whatwg/html/issues/1903
,
Nov 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2dc94fb317678bbdbe32e43d7d807b7506d16d08 commit 2dc94fb317678bbdbe32e43d7d807b7506d16d08 Author: Mustaq Ahmed <mustaq@google.com> Date: Thu Nov 30 03:30:56 2017 Enable consuming activation in frame tree, extent expiry time. We are switching to the consumption model since Safari 11 seems to be matching Chrome & Edge now regarding this. The activation expiry time is also increased to 1h to evaluate if the simplest model with no expiry (together with consumtion to confine its "reach") works as expected. Bug: 776404 Change-Id: Ib452689131bc0426f0bb39ba91fcee22d4ac5756 Reviewed-on: https://chromium-review.googlesource.com/794109 Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Cr-Commit-Position: refs/heads/master@{#520416} [modify] https://crrev.com/2dc94fb317678bbdbe32e43d7d807b7506d16d08/third_party/WebKit/Source/core/frame/Frame.cpp [modify] https://crrev.com/2dc94fb317678bbdbe32e43d7d807b7506d16d08/third_party/WebKit/Source/core/frame/Frame.h [modify] https://crrev.com/2dc94fb317678bbdbe32e43d7d807b7506d16d08/third_party/WebKit/Source/core/frame/UserActivationState.cpp
,
Aug 22
We finally decided to avoid no expiry time. The 1h expiry experiment caused some issues with APIs that never consumes the activation. Moreover, Firefox added an expiry time sometime last year: https://github.com/whatwg/html/issues/1903#issuecomment-325802724
,
Aug 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/afbd8031cd5bb608076a0a9a527228f90167e3c5 commit afbd8031cd5bb608076a0a9a527228f90167e3c5 Author: Mustaq Ahmed <mustaq@google.com> Date: Wed Aug 22 17:07:39 2018 UAv2: Bring expiry time down from infinity to half a minute. The transient bit in UserActivationState is a proxy for the state that "the user is currently active with the page". From a logical perspective, this state should expire/reset after a certain period of users' inactivity. Chrome's current expiry is 1sec (but can be 10secs in certain cases). As of mid-2017, none of Edge, Firefox and Safari had any expiry time, so we wanted to explore the simplest possible design for UAv2---w/o any expiry. This created issues with APIs that never consumes the activation, and we learned that Firefox also added an expiry time last year. Hence we are bringing down the experimental 1h expiry time here. Bug: 776404 Change-Id: I640c22805c8d4db74812a02d24e645aa994dc20f Reviewed-on: https://chromium-review.googlesource.com/1178746 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Mounir Lamouri <mlamouri@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#585106} [modify] https://crrev.com/afbd8031cd5bb608076a0a9a527228f90167e3c5/third_party/blink/common/frame/user_activation_state.cc [modify] https://crrev.com/afbd8031cd5bb608076a0a9a527228f90167e3c5/third_party/blink/common/frame/user_activation_state_unittest.cc
,
Aug 22
,
Nov 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3ecce3d47c6e316bc8e6a833bb13501801a138eb commit 3ecce3d47c6e316bc8e6a833bb13501801a138eb Author: Mustaq Ahmed <mustaq@google.com> Date: Tue Nov 06 20:42:19 2018 Change UAv2 expiry down to 1 sec. This is done as per the interop disucssion in UAv2 intent thread: we decided to try 1 sec timeout first, and would switch back to a longer expiry if see any compat problem (specially in a slow network). https://groups.google.com/a/chromium.org/d/msg/blink-dev/nkTDR8AUlwM/RVHaoPgLCQAJ Bug: 776404 Change-Id: I228eb9d2426d07c3f796ccdad14e7185fa06f98e Reviewed-on: https://chromium-review.googlesource.com/c/1320021 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/heads/master@{#605812} [modify] https://crrev.com/3ecce3d47c6e316bc8e6a833bb13501801a138eb/third_party/blink/common/frame/user_activation_state.cc [modify] https://crrev.com/3ecce3d47c6e316bc8e6a833bb13501801a138eb/third_party/blink/common/frame/user_activation_state_unittest.cc |
||||
►
Sign in to add a comment |
||||
Comment 1 by mustaq@chromium.org
, Oct 19 2017