autoplay video, vibrate, and top-navigation from cross-origin frames

[Ojan Vafai]

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.

1. 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.
   
2. 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.
   
3. 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?

[Dru Knox]

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?

--
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.

[Bin Lu]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.

[Ojan Vafai]

We tried really hard to make Site Engagement work for this, but kept struggling to get the square peg to fit in the round hole. In the end, we decided that the ever had a gesture thing was simple and actually completely solved the problem, so it didn't seem worth exploring something more complex. 

+Dominick Ng +Kendra Carattini if they have anything to add there.

Also, +input-dev should probably be looped in on user gesture questions.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.

[Ojan Vafai]

Gating autoplay sound on Site Engagement is one example of where it seems like a good fit at first until you get into the details. 

Imagine a music sites that automatically take you to the next song when the current one finishes that you leave open always playing much (e.g. as the sound system for a cafe). It some point (e.g. after a week), your engagement score will drop low enough that the audio stops playing. I guess you could say playing sound should accrue engagement scores, but I'm not sure if that generalizes (e.g. to vibrate).

Mounir's has a proposal to create a media engagement score. I filed crbug.com/700689 to show that the concept could be extended to other APIs like vibrate. A difference from site engagement is that it decays based of page loads, not time and it doesn't decay if the site continues using the API in ways the user is likely to approve of.

[Dominick Ng]

The sticky gesture bit does feel like a much more predictable solution to trying to gate vibrate. I'd be very interested in cross metrics between the engagement of sites which end up having vibrate allowed under this scheme to see if we can find correlations.

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.

--

 -Dom.