IIUC, the concern of using site engagement is that it makes the behaviors of those functions somehow unpredictable or inconsistent (something like, say, vibrate or top-navigation might work on some sites, but not others), and the developers would be very confused.There were some discussions about exposing an API for developers to detect the existence of user gesture, but I'm sure if someone is working on it or not.Do (or should) we have a similar API for site engagement score that developers can use? If yes, it might alleviate the unpredictability concern.For maintaining the bit, should we consider same origin navigation (instead of same-domain)? For example, a user searches something on google.com, and then get redirected to some hosted content on drive.google.com after click, would we carry the bit to drive.google.com? On the other hand, I'm thinking if the login/payment frames might change their origins during the process, say, from pay.pay.com to succeed.pay.com.On Thu, Mar 9, 2017 at 9:53 PM, Dru Knox <dk...@chromium.org> wrote:Potentially naive question: what were the reasons we settled on using a gesture instead of site engagement? Wouldn't site engagement persist navigations and give us this behavior too?Either way though, maintaining the bit for same domain navigations seems reasonable to me. Is there a simple way for the developer to detect that they've received such a gesture? Especially if the bit persists navigations, it won't be possible to just listen for click events, right?On Thu, Mar 9, 2017 at 4:59 PM 'Ojan Vafai' via intervention-dev <interven...@chromium.org> wrote:--We have 3 interventions that are part-way through development/shipping that use a bit on whether a frame has had a user gesture. Since it's on the frame and not the document, it survives navigation.
- Vibrate: We've shipped a restriction on vibrate in cross-origin frames to require the bit to vibrate. We're planning on extending this to top-level documents, but not have it survive navigation in that case.
- Top Navigations From Subframes: We're also working on shipping that we only allow cross-origin frames to navigate the top page from frames that have had a gesture.
- Autoplay: We're just starting to consider whether we should use this same bit for autoplay video on mobile instead of the current user gesture but don't consume the gesture behavior.
The reason we landed on the behavior of this bit surviving navigation was for real world compat for intervention #2 above. In thinking about the autoplay case though, there are top-level sites (e.g. youtube) that we've forced to go into contortions into being single page apps just so that they can keep the ability to play video.Mounir had that idea that we could have this bit survive top-level navigation if it's a same-domain navigation. Which then got me thinking, could we just have that be the logic for both top-frame and sub-frames for all three of these interventions? I think that might get the same real world compatibility that we gained from allowing all navigations of subframes to transfer the bit.This way, top-frame and sub-frames would behave the same and we wouldn't need special cases like https://codereview.chromium.org/2721423003/.WDYT?
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTuqMa8OvWBCWTSU_j6LUZv7wVMA8xaBgKHpOEQpJix%3D1A%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTuqMa8OvWBCWTSU_j6LUZv7wVMA8xaBgKHpOEQpJix%3D1A%40mail.gmail.com.