FWIW your extension works correctly for me in Windows and returns "done with executeScript: [true,true]" on both URLs.
See if you can reproduce the bug in a separately installed Chrome Canary.

Thank you for checking! It looks like maybe I hadn’t properly reloaded my test extension after changing manifest settings. Here is an update…

When I test on this URL: https://mrcoles.com/media/test2/scratch/iframe2.html

1. It works when all tabs permissions are required (`["tabs", "http://*/*", "https://*/*", "activeTab"]`), e.g., on master: https://github.com/mrcoles/test-chrome-extension-executeiframes
2. It *does not work* when I only the activeTab permissions is required (`["activeTab"]`), e.g., on feature/only-activetab: https://github.com/mrcoles/test-chrome-extension-executeiframes/tree/feature/only-activetab

If I try a page that has an iframe on the same domain, then the activeTab variation does succeed in getting that frame: https://mrcoles.com/media/test2/scratch/iframe.html

Why is a frame of a different domain within the active tab not available to executeScript when the extension has the activeTab permission? This seems to be a bug.

Simplified repro:

1. install the attached extension
2. open https://mrcoles.com/media/test2/scratch/iframe2.html
3. click the extension icon

Expected: "SUCCESS" is shown
Observed: "FAILURE" is shown

Bisect info: 332704 (good) - 332711 (bad)
https://chromium.googlesource.com/chromium/src/+log/bfee1d04..4d403f2a?pretty=fuller
Suspecting r332710 = f994d1efce89b17cf3443ee5a7750e805b44a0e9 = https://crrev.com/1150683007 by rdevlin.cronin@chromium.org
"[Extensions] Use document url (not top url) for tab-specific permissions"
Landed in 45.0.2422.0

Quoting the CL description:

    Fix a bug where activeTab would grant script access to all frames in a tab,
    instead of just the top one. Also remove the top_document_url parameter from
    CanAccessPage and similar methods.

It's not clear why the previous behavior was considered a bug. 
I'd say it's the other way around: the new behavior is a bug:

* The documentation says the permissions are granted to the tab,
  it doesn't say "to the main frame and its same-origin subframes",
  the permission is named "activeTab", not "activeTopUrl", so it must expose the entire tab

* The new behavior undermines usefulness of the activeTab permission:
  for example, extensions can't apply custom CSS (a dark theme or whatever) to the entire tab

Deleted: test-activetab-executeScript-ext.zip 1.4 KB

test-activetab-executeScript-ext.zip 1.4 KB Download

FWIW, activeTab opens the entire tab in Firefox as per the documentation.
Of course it doesn't concern Chrome since it doesn't implement the WebExtensions API, but still...

Able to reproduce the issue on chrome version 65.0.3325.181 using Mac 10.12.6, Ubuntu 14.04 and Windows-10, hence as per comment# 5 providing the bisect information, issue is also seen on latest beta# 66.0.3359.45 & canary# 67.0.3382.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/bfee1d04..4d403f2a?pretty=fuller
Commit: https://chromium.googlesource.com/chromium/src/+/f994d1efce89b17cf3443ee5a7750e805b44a0e9
Review URL: https://codereview.chromium.org/1150683007

@rdevlin cronin: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

This isn't a regression, as it was an intentional change.

For background on the motivation:
If a user grants permission to an extension to run on a tab, the user may not be aware of all the origins that are contained within that tab.  One of the big concerns is that so many sites (particularly social media sites) implement embeddable elements as iframes (with separate origins).  For instance, every "like" and "+1" button in existence. :)  If we allow an extension to have origin access to every frame on the tab, then by granting the extension access to a site that has these elements (say, a blog site), the user is also granting access to the embedded sites (like google.com and facebook.com).

This is a pretty serious concern, and we couldn't figure out any sensible way to inform the average user that they are, in fact, granting this permission to more than just the site they think they are viewing.

This gets more complicated when frames are modified on the tab.  If you allow the extension to execute script on every frame in a tab, including those that are not created at the time of injection, then the extension could modify the page to include a frame to a different domain, and effectively increase its own permissions.  If you restrict to those origins that are in the frame at the time of injection, then frames that are created later or navigated (which can happen frequently with e.g. ads) are omitted.

We could rely on sites properly setting CSP or XFrame options to enforce whether or not another site could embed them, but that is pretty limited - for one thing, not enough sites do that, and for another, it wouldn't help in the case where the site encourages embedding via an iframe (e.g., like buttons, facebook comments, etc).

If firefox does indeed allow access to all frames on the tab, I'd be interested in what they do in these cases, and whether it would be possible for a malicious extension to exploit activeTab by creating their own frames.

Now, all that said, we *are* aware that this is an issue with activeTab, and that it is both confusing and limiting in the usefulness.  We're exploring what we might do here, and one of the options is indeed to just allow everything, and hope that the requirement for the user to invoke the extension is sufficient enough.  But it's something that we need to discuss more before making any decisions.

Thank you for sharing the insightful response of security concerns.

To share my use-case, I’m trying to scroll through the visible contents on a page when the user activates the extension. When I receive complaints about it not scrolling the entire page, it is usually a page that uses iframes (or occasionally framesets) to sometimes put a wrapper around another site or embed a complicated UI (like a website editor) and these often have different domains or at least different subdomains.

Regarding the issues you described and how they affect my use-case:

1. being able to executeScript inside new frames: I personally do not need access to iframes that were created after the extension was activated, but I would want access to iframes that were added to the document before my extension was activated.

2. being able to access sites hosting like buttons: I don’t need access to these, but obviously, there would need to be an understandable generalized approach here, perhaps iframes with 0 height or width could be excluded? Anecdotally looking at Buzzfeed, I see a lot of iframes with width=0 and height=0, but the comments are hosted by www.facebook.com in a 600x670 box and there are a bunch of tpc.googlesyndication.com 300x250 display ads. IMO, the facebook comments and google ads are so seamless with the page that as a user of an extension I would think they’re just part of the active tab.

Let me know if I can contribute any more to the discussion!

Has there been any more discussion one way or another on this?