Require a user gesture for a cross-origin frame to navigate the top-level page

[ojanvafai]

We are seeing a lot of ads that navigate the top-level page outside of a user gesture. We think this is user hostile and that we don't lose any important use cases by requiring a user gesture. Chrome has added formal measurement for this. Once we get the numbers back, we plan to make this change.

There is also the allow-top-navigation flag for iframe sandbox attribute. Once we make this change the plan is that sandbox disallows top navigation and allow-top-navigation allows the behavior described above (i.e. even with allow-top-navigation, you'd still need a user gesture to navigate the top-level page).

[MattMenke2]

Any consideration of doing this for modal dialogs as well? When I saw the email about not opening "popups" except in response to a user gesture, was excited about this because I thought it included blocking that particular behavior as well. A lot of abusive pages use OnBeforeUnload dialogs, which are just annoying.

[mikewest]

blink-dev thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Xi8-y4ySjA4/dc4BFfqyBQAJ

/cc @annevk @rlbmoz @johnwilander @travisleithead

[hillbrad]

:( This breaks a thing I'm working on. I'm trying to expose a cross-origin API in an iframe via postMessage. The parent frame uses postMessage to request a service from the iframe. If the request can be fulfilled without user confirmation, the iframe navigates the parent to a "success" page specified by the caller. Otherwise it makes a POST that navigates the parent frame to a confirmation page, which takes the user back to the specified "success" page after the user gesture.

I like the iframe top navigation pattern for a couple of reasons.

Compare it to the traditional workflow for doing this (as with OAuth) which requires POSTing directly to the cross-origin resource or opening a popup:

• If user consent isn't required the user is taken directly to the "success" page without incurring a synchronous additional round-trip and redirect in the top frame, giving better perceived performance, responsiveness and less drop-off.
• Popups suck and are frequently blocked.

The parent could implement another listener for a postMessage reply and do the navigation itself, but that makes using this kind of API more complicated, and it is nice to be able to do the POST from the iframe and include, e.g. a CSRF token and trustworthy indication of the parent origin that triggered the request.

A click to the iframe doesn't make sense; it takes away control over the UX that the parent wants.

Since a page that doesn't want this behavior from an iframe already has the ability to block top-navigation with the sandbox attribute, I'm not sure why we need to break this behavior by default?

Could we count receiving a postMessage from the parent as enabling navigation? (in addition to a user gesture)

[ramanathanrv]

For payments security, we collect sensitive card information within an embedded iFrame. A lot of our clients depend on our iFrame for this. Once the card information is collected in the iFrame, the user is then navigated (by changing window.top) to a page in our domain for authentication of the card information. This proposed change will break our flow permanently.

If allow-top-navigation is mentioned in the