New issue
Advanced search Search tips

Issue 452944 link

Starred by 6 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 14
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Add activeTab.allFrames permission

Reported by, Jan 28 2015

Issue description

What steps will reproduce the problem?
1. Have an extension which wants to inject a script onto all frames when browser action is clicked
2. Convert from using <all_urls> to activeTab
3. User clicks browser action

What is the expected output? What do you see instead?
The extension should keep working, because activeTab is better than <all_urls>. However, it can't, because with our current design of activeTab we don't propagate the permissions to frames.

This was a deliberate decision. Facebook "Like" buttons, Google+ "+1" buttons, etc, are all iframes which activeTab would grant access to if it granted to all frames. At the same time, extensions which really do need an all frames capabilities (like readability extensions, ad blockers, whatever) must have all frames access.

I propose adding an activeTab.allFrames permission, which extends the activeTab permission to give access to all frames on the page as well. Worst case we can treat this like an <all_urls> warning. Best case is that we can find a UI or policy to reconcile that this can be given the same install warning as activeTab (i.e. no install warning).
Project Member

Comment 1 by, Mar 16 2016

Labels: Hotlist-Recharge-Cold
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue.

For more details visit - Your friendly Sheriffbot
I think this remains a relevant enhancement to pursue.

I stumbled over this limitation recently (see "AllFrames Isn't Always" in and it took some time to figure out.

Even if we don't add activeTab.allFrames as a new permission, I think we should at least update the public documentation to clearly explain the same-origin restriction on the allFrames flag.

Comment 3 by, Sep 30 2016

Potentially terrible suggestion from a UX point of view, but an option is to ask the user for permission to grant origin access to iframes when activeTab is used:

"SomeExtension wants to read your data on, et.c. Yes/No?"

Simply doing that would trigger lots of confirmation prompts, so we could give the extension an option to list which origins they are interested:
// manifest.json
  permissions: ["activeTab"],
  active_tab: {
    iframe_permissions: [

Then the confirmation prompt for iframes would only trigger for iframes that the extension can access.

On second thought, this already seems doable using |optional_permissions|: The extension enumerates iframes on the page, requests permissions for the ones it's interested in using chrome.permissions.request, and then accesses the iframes and modifies their content.

Re: #3, Can an extension without permissions for all_urls even collect the URLs (or hostnames) of cross-origin iframes? I'd imagine you could grab the initial source attribute, but if there were a redirect (or a descendant subframe) I wouldn't expect those URLs to be visible...
Just checked and the src URLs are indeed visible even after a navigation. The src URL doesn't say anything about whether the iframe content is successfully loaded though (the example displays for the second iframe even though it can't be iframed).
1.5 KB Download
And of course, you wouldn't be able to get any descendant subframe in the first pass. You could get that after obtaining the permission for the first level iframe origin and then recursively doing the same thing :)
In the demo, change the URL of one of the subframes so that it points to a page that has links on it (e.g. and then click on one of those links (e.g. the blue "Gratis" image in the middle of the page). Observe that the SRC still reflects the original SRC of the frame ( not the current SRC (

Ah okay, didn't realize the two cases were different. Makes sense, in the first case page redirecting the iframe already knows the URL so no problem allowing access to it. In the second case user navigates the iframe so the outer page won't get to know about it.
@3 One of the main goals with activeTab is the ability to run on an arbitrary site.  Previously, extensions would use <all_urls> to do this, even if they only needed to run on click.  That use case still remains, so having the extension specify in the manifest is probably too limited in many ways.
Project Member

Comment 10 by, Oct 4 2017

Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
We've had numerous conversations about this, and I think we're pretty confident that we no longer want to do this.  We would need to ensure that the extension didn't have access to frames it itself added (which would be privilege escalation), and do so would also mean that we'd have to track each interaction of the extension on the page (e.g., through content scripts, webRequest, etc) to verify when we were certain that frames weren't added by it.  Doing that introduces significant complexity, and offers dubious benefit for real-world use cases.  Combined with the significant user confusion this would likely cause, and I think we probably don't want to pursue this.

Sign in to add a comment