Open Bug 1359867 Opened 3 years ago Updated 1 year ago

Add attribute allow-top-navigation-by-user-activation to iframe sandbox


(Core :: DOM: Core & HTML, enhancement, P2)





(Reporter: binlu, Unassigned, NeedInfo)



(Keywords: dev-doc-needed)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36

Expected results:

There is a new attribute proposed to iframe sandbox:

This is a follow-up work of

The new attribute requires a user activation (or gesture) being processed to trigger a top-level navigation. This change would enable more use cases of sandboxing untrusted third-party contents (eg., ads) by allowing top navigation while blocking malicious auto-redirecting, and thus help building a safer internet (eg., a safer ads ecosystem in which all ads could be sandboxed to prevent unexpected malicious behaviors like plugin exploits, auto-redirects, file downloading, modal dialogs, etc). 

For more context:
Component: Untriaged → DOM: Security
Product: Firefox → Core
The big problem here, of course, is defining "user activation" in a sane way...
Ever confirmed: true
Severity: normal → enhancement
Component: DOM: Security → DOM: Core & HTML
Priority: -- → P2
An update: 
In addition to Chrome, Webkit (Safari) has landed CLs to support this:
Ad networks have started to use this feature to prevent malicious behaviors (like plugin exploits, auto-redirects, etc) from third-party contents (eg., ads).

It would be great if Firefox could support this soon. Thanks.
Again, the big problem is defining "user activation".  Browsers define it totally differently, and Gecko has at least three different internal definitions I'm aware of.... We'd need to at the very least pick one of those definitions.
Thanks Boris for the reply!
I have no knowledge on how Gecko defines "user activation", but I guess anything reasonable should be fine although browser interoperability would be great. FYI.: Here is a link to how Chromium defines "user activation":
We're also working on a proposal for a) simplifying this in Chrome and b) standardizing the new behavior once we've proven to ourselves that it's web compatible. We haven't quite gotten around to sharing it anywhere yet though. Will try to do soon.
Hello, Any update on this?

Ad networks are increasing adopting iframe sandbox, e.g, the % of page views with iframe sandbox has jumped to ~8% from ~0.4% last May (, and there are also some tech articles talking about this "allow-top-navigation-by-user-activation" attribute now:

It would be great if Firefox could support it. Thanks.
Flags: needinfo?(overholt)
Wanted to add my support for this.   

The following browsers support this

We see it working in the following browsers
Chrome for desktop release 58
Chrome for Android release 58
Android WebView release 58
Opera release 45
Opera for Android release 45
Safari Tech Preview 48

It looks like IOS 12 will have this rolled out but we are hoping Apple deploys sooner given the security aspect of the issues.

Force browser redirects is the primary method being leveraged by bad guys to distribute malware and fraud.  Here is a good recent article on a giant network exposed by Confiant and another one by GeoEdge
This isn't being actively worked on right now.
Flags: needinfo?(overholt)
comment 2 and comment 4 are still the main issues here. 

We don't really follow the last step of 
I wonder what other browsers do, exactly.
(first two steps are sort of handled
I /think/ the general idea of "chain of algorithms" in the spec is that anything that is "ultimately" triggered by a user action is treated as such.  For example, a click event handler that sets a timeout function that sends a postMessage... The spec line meant to cover all such cases through this recursive definition.

Chrome maintains and passes on (stack-scoped) UserGestureTokens to allow following the "chain".  But it is far from being complete, sometimes simply because we didn't really get a chance to fix it (e.g. for Promises:, sometimes because of implementation complications.  There are cases where we break the chain deliberately; e.g. we don't allow setTimeouts beyond depth 1 perhaps to disallow tricky multiple-popups-per-activation cases.

I doubt if any browsers fully implements the spec.

Currently we are implementing a new simple model ("User Activation v2") where activation states are stored in frames, and propagated up the frame tree (so chaining/stack-scoping won't be needed).  We are fighting regressions now :( .  *If* everything goes well, we plan to propose a new spec (

(A separate thread with MS last month seemed to suggest that Edge does something close to our v2.)
At least some of the "is user activation" bits in Gecko explicitly report "no" if it's been too long such that users would not perceive the thing that happens as a response to their action.
Blocks: 1419262
Olli, Thanks for looking into this.
Have Mustaq and Boris's explanations answer your question?
Is there any other concerns/blockers on implementing this? Thanks.
Flags: needinfo?(bugs)
The concern is the same as it was all along: definition of "user activation".
The spec has a definition. It's known not to be perfect (, and Chrome is investing some resources into working on that.

But I am hopeful that in the meantime that browsers are still willing to ship features that take advantage of user activation, just like they've done with e.g. the notifications API, the credential management API, service workers' clients API, recent work to move the vibrate API behind user activation, etc. ( seems informative.)

In other words, I'm not sure why this feature in particular would be held up by trying to perfect the definition of user activation, when Firefox has shipped many other features based on it.
The real question is to what extent we need to worry about compat fallout.  That needs to be decided on a case-by-case basis.  Navigation not working is obviously a bigger compat problem than notifications not working, for example.

But yes, we can of course just ship something and then hope that we don't break too many sites when we end up changing behavior later.  That still requires us deciding what the "something" we ship is, because Gecko has multiple different concepts that sort of look like "user activation", as I said above.  And that needs someone with time to sit down and think about how this will be used in practice and which of those concepts best maps onto the use cases.
Two points re the "user activation" worries:

- For popups in major browsers, we hardly found any consistency from this perspective:

- Since you mentioned the need for a thorough look: in Chrome we are doing exactly that today.  For User Activation v2, our end goal is to replace Chrome's hacky old system with one that simple enough for cross-browser implementation.  Feel free to comment on our design:
Received confirmation from Microsoft team that this is now in their dev queue.  Would really love to see a path forward.
It seems like the biggest hangup here is lack of clarity around "user activation". What specific questions do we need answered? Should we check with the Edge team on what they are planning on doing? Or is it just like Boris says in comment 16 that someone needs to sit down and think about it?
Flags: needinfo?(bzbarsky)
I think we just need to sit down and think about it, though checking what other UAs are doing could be useful input, sure.
Flags: needinfo?(bzbarsky)
Flags: needinfo?(echen)
1. Most of user-activation in Gecko is based on whatever EventStateManager::IsHandlingUserInput[1] returns. And it treats key events (except Esc, Shift, Ctrl, Alt ..), mouse events and pointer events as user input. (Spec treats contextmenu as user-activation, but Gecko doesn't)
2. The user-activation for Fullscreen adds 1000ms timeout [2].
3. The user-activation for popup has a whitelist [3] + all access key [4].


See for motivation. "While Chrome (versions 58 and later) has enabled the control, Firefox, Safari, and Internet Explorer prior to 10 have not."

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #22)

See for motivation. "While Chrome (versions 58 and later) has enabled the control, Firefox, Safari, and Internet Explorer prior to 10 have not."

Just a clarification: Safari has supported this on both Mac & iOS since April 2018:, which is also mentioned above.

So with Edge moving to use Chromium, Firefox would be the only major browser not supporting this.

FWIW, here's an example of where another major open source project could take advantage of this if it existed, which would improve UX for millions of users:

You need to log in before you can comment on or make changes to this bug.