Do we know if fixing this bug would really cause any visible regression?  I recall dcheng@ mentioning (during a BlinkOn8 talk) that the reuse of an old LocalFrame for a new Document depends on certain conditions.  Do we know how frequent/rare it is?

I suspect it must be rare because otherwise we would hear user complains about false autoplay in subframes.  Mounir, any comments?

Reusing a LocalFrame happens quite often: clicking on links to navigate around will rarely swap processes, causing the main frame's LocalFrame to be reused.

This implies that clicking on a subframed link to an "autoplaying site" would start the autoplay even if user never interacted with the new site.

Mounir, can we really reproduce this behavior?

I'm not sure what's the question here and I can't remember why the flag is only reset for main frames. I can't think of any reason why not resetting it for all frames but dcheng@ and beccahughes@ are the people in the know here.

+ japhet

There was some discussion here about clearing unconditionally.

https://chromium-review.googlesource.com/c/chromium/src/+/524046

TLDR; clearing the bit unconditionally is preferable but we should check with anyone who is using the bit.

Since everyone agrees (here and in the CL) that clearing the bit unconditionally is better, we shouldn't hold back this simple fix just because of the fear some API might be depending on it.

Here is a list of current APIs using the bit, I don't think any of them would want a new subframe to hold on to an old subframe's user gesture:
https://docs.google.com/document/d/1mcxB5J_u370juJhSsmK0XQONG2CIE3mvu827O-Knw_Y/edit#heading=h.yyq2kfsykkx9

---

Let me clarify my comment #c3 above: it should be easy to prove that this conditional reset is bad, through a repro as follows:
1. Let main frame A have a subframe B.
2. Make the user click/interact with B (to set the sticky bit).
3. Replace subframe B to a new autoplaying site.
The new site shouldn't autoplay since user never interacted with it.

beccahughes@chromium.org: could you please check if this works as expected or not?

Temporarily assigning to beccahughes@ for the correct expectation and current Chrome behavior question in #c7 above.  Or you can create a repro for me to test.

This came up today while discussing web-platform-test expectations for JS-exposed activation state, see crrev.com/c/1076979.

I agree with the argument in #7, but I'd suggest double checking with japhet@ and ojan@.  IIRC they had a case where carrying over state from the previous document in a frame was actually part of the design, but I forget the details (probably for japhet's intervention of navigating from frames without a user gesture).

japhet@, ojan@: do you have any pointers to the design Rick mentioned?

I suspect from Rick's comment that the need to preserve the info may have been a result of the shared UGI state across frame boundary: a subframe navigating away shouldn't logically affect parent frame's user activation state, but it's a shared state so consuming only in the subframe was not an option.

With UAv2's per-frame state, it seems logcal that we may not need to carry activation state across navigations in subframes.  Wdyt?

The new autoplaying site should not autoplay unless the new site is on the same eTLD+1 (we use has_received_user_gesture_before_nav for that though).

Here is a repro that you can use:

http://rebeccahughes.github.io/media/subframe-test/

The page with the video is on a different site.

It looks like that repro is on the same eTLD+1 so I have created another:

https://rebeccahughes.github.io/media/subframe-test-etld/

I will give it a try next week.