I have the same problem in current beta 67.
This bug now greatly affects my extension "GroupSpeedDial" which is making screenshots of its own page (which is of course "chrome-extension://" page). Own extensions pages should be always allowed for screenshots.

I have also facing same problem with url start from chrome-extension://, looks like the issue occured due to recent changes in Chrome-67. Respected changeset - https://chromium.googlesource.com/chromium/src/+/0aca6bc05a263ea9eafee515fc6ba14da94c1964

I verified that for url start from 'http/https', 'file://' and 'chrome://' are working correctly.

From https://chromium.googlesource.com/chromium/src/+/0aca6bc05a263ea9eafee515fc6ba14da94c1964 this sounds like it might be expected?

Correct, this is more-or-less WAI.  The <all_urls> permission grants access to any URL that extensions are allowed to run on, but there are a number of URLs that extensions cannot run on - including chrome-extension:// and chrome-devtools://.

meacer@, we relaxed the check for permission for chrome:// URLs if activeTab is present and granted - I wonder if we could/should do something similar for chrome-extension:// or other schemes?  WDYT?

 Issue 850643  has been merged into this issue.

I am able to reproduce this issue with `captureVisibleTab` failing in the chrome webstore in Mac OSX 10.13.2 and Chrome 67.0.3396.79. It does not happen with chrome://newtab or chrome://apps.

I am concerned that my  issue #850643  was marked as a dupe of this. It seems related, but it has to do with `chrome.tabs.executeScript` and it *only* fails for packed extensions, while it works fine for unpacked extensions.

Re comment #5:

By "if activeTab is present and granted", did you mean active tab on top of <all_urls>? 

> I wonder if we could/should do something similar for chrome-extension:// or other schemes?  WDYT?

At the very least, chrome-extension should be able to capture their own pages.

The main reason we don't allow extensions to run on chrome-extensions or devtools URLs is that we don't want extensions to script those. And extension A capturing extension B allows A to steal B's secrets (bad for password managers and other sensitive extensions). But given that extension to extension capture has been possible with only <all_urls>, allowing it again and gating by a user gesture (the browser action) might be OK.

Devtools is a bit different: The extension requires <all_urls> permission, so for sites it already has access to (i.e. non extension URLs), there is no added risk in having access to the page's devtools contents. It's also possible that the devtools content is of a chrome-extension page. In that case, we should allow or deny based on what we do for the capture of chrome-extension URLs.

So to summarize, the options are:
1)
- Allow capture of all chrome-extension URLs
- Allow all devtools URLs
2)
- Don't allow capture of chrome-extension URLs
- Allow devtools URLs except for those that are inspecting chrome-extension URLs

@8 Per  bug 810220  and revision 0aca6bc05a263ea9eafee515fc6ba14da94c1964, the current behavior we came up with for capturing permission is:

- If the page is a "normal" web page (e.g., http/https), allow the
  capture if the extension has activeTab granted or <all_urls>.
- If the page is a file page (file:///), allow the capture if the
  extension has file access *and* either of the <all_urls> or
  activeTab permissions.
- If the page is a chrome:// page, allow the capture only if the
  extension has activeTab granted.

> But given that extension to extension capture has been possible with only <all_urls>, allowing it again and gating by a user gesture (the browser action) might be OK.

I'm not sure I follow this.  Do we really want to allow this?

The devtools case is interesting, and I think we could *probably* allow it if the extension has access to the inspected page and <all_urls>.

@8 - does your summary discard the idea that extensions should be able to capture their own pages? I would really appreciate if this were restored.

Also, what about how previously (v66) extensions could `chrome.tabs.captureVisibleTab` webstore URLs, e.g., https://chrome.google.com/webstore/category/extensions -- might that return?

> does your summary discard the idea that extensions should be able to capture their own pages? I would really appreciate if this were restored.

I think that we can treat this similarly to web pages - requiring either activeTab or <all_urls> (we have to have these restrictions for the same reason we need them on the web - the top-level page may have embedded iframes with sensitive information).  Looking at the code, though, I think this may still work - have you tried this with an extension with activeTab or <all_urls> and verified it fails?  (I haven't had the opportunity to confirm either way, but hopefully can later today or next week.)

I am unable to get `chrome.tabs.captureVisibleTab` to work for an extension running on one of its own pages. This is new in v67.

1. Webstore extension:

> Cannot access contents of the page. Extension manifest must request permission to access the respective host.

2. Local unpacked extension:

> Cannot access contents of url "chrome-extension://jmjgaicjdbgdmakgbgoekgmleefkhdpg/index.html". Extension manifest must request permission to access this host.

We're still discussing a bit what all the proper behavior should be here to respect user settings and other restrictions, but it's pretty clear there's some work to be done.  Assigning to myself.

(whoops - meant P1, not P0)

I believe there is a real bug in URL matching, when matching IPv6. For some reason IPv6 addresses are not allowed:

http://[2002:a65:32aa::]:10000/  [doesn't work]
http://10.10.123.17:10000/       [works]
http://hostname:10000/           [works]

Hi it's affecting the internal extension snipit too. In our case it can't capture file:// images either.

Note snipit does *not* have <all_urls>, but it uses the activeTab permission instead.

Re c#16, does it work ok if the "Allow access to file urls" is checked? Also see https://chromium-review.googlesource.com/c/chromium/src/+/1096352 which ensures the toggle is visible for any extension with activeTab.

@karandeepb, where do I toggle "Allow access to file urls"? I vaguely remember seeing this phrase somewhere but I don't see it on chrome://extensions/ on 67.0.3396.79 (Official Build) (64-bit).

It's in the extension's entry details, also accessible by right-clicking the extension's icon in the browser toolbar, and then clicking "Manage extensions".

Correct. Also, there was  issue 850643  which dealt with the toggle not appearing when it should with activeTab, but that is now fixed.

@16: Not being able to capture file:// URLs *without* file access permission is WAI, as karandeepb@ points out.

I chatted with meacer@ about this at some length, and we've come up with something that we think we're okay with from a security perspective.  It's not as permissive as it used to be (because the old version had some questionable security properties), but it should allow for most of the use cases we have here.

For each host type, the required permissions are listed.

<arbitrary web page> (e.g., https://example.com): activeTab OR <all_urls>
file:-scheme page (e.g., file:///etc/passwd): (activeTab OR <all_urls>) AND explicit file access from chrome://extensions.
Pages restricted by enterprise policy: blocked (note: only if the page is blocked for the specific extension; otherwise default behavior for the host applies)
Extension's own page (e.g., chrome-extension://<myid>/foo.html): activeTab OR <all_urls>
Another extension's page (e.g., chrome-extension://<otherid>/bar.html: activeTab
chrome:-scheme page (e.g., chrome://settings): activeTab
IPv6 pages: Behave like normal web pages
Pseudo urls (filesystem:, blob: etc): Behave like the underlying origin

The reason we have different levels of permission (e.g., chrome:-scheme and other extension's pages only being accessible with activeTab, but not with <all_urls>) is in order to provide a stronger guarantee that the user's intent was to capture the visible page.  Since extensions cannot normally run in this context, we need to be a little stricter than we would otherwise.

We should also update the documentation (which is currently very unclear about which pages may or may not be allowed) to include this information.

I've updated the summary to match this, and will work on a patch.  I doubt this will make M67 (which has already shipped), but we should be able to get this into M68.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/955451dfb49b6cf59dc805737773e944701f9202

commit 955451dfb49b6cf59dc805737773e944701f9202
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Tue Jun 19 15:53:02 2018

[Extensions] Update captureVisibleTab permission checks

tabs.captureVisibleTab() is interesting. It used to work with every
URL ever, and just checked for if activeTab or <all_urls> was present.
However, this led to some issues where the extension could capture pages
it shouldn't be able to, such as  https://crbug.com/810220 .

Changing this to only allow access to pages that the extension had
explicit access to also broke important use cases. For instance, taking
screenshots of chrome:-scheme pages is important for filing bugs,
tracking features, etc. This similarly broke use cases for other URLs
that extensions don't have full access to, like other extensions' pages.
An exception was added for chrome:-scheme pages, but this was
insufficient for other cases.

Adjust the permissions check to allow page capture of otherwise-
restricted pages if the extension has activeTab granted. We require
activeTab (rather than either <all_urls> or activeTab) because it gives
a stronger guarantee that the user wants the extension to run on the
given site.

Note: this does not allow any other action on these restricted pages;
only capturing the page is permitted.

The new behavior enforces the following permission requirements for
the host types:
<arbitrary web page>: activeTab OR <all_urls>
file:-scheme page: (activeTab OR <all_urls>) AND
                   explicit file access from chrome://extensions.
Pages restricted by enterprise policy: blocked
Extension's own page: activeTab OR <all_urls>
Another extension's page: activeTab
chrome:-scheme page: activeTab

Support for IPv6 pages and pseudo urls is dependent on these being
properly supported with activeTab, which will be pursued in a followup.

Bug:  839857 

Change-Id: Ied3a71732cd5d41ad16f9b459f6fda9b1815edaf
Reviewed-on: https://chromium-review.googlesource.com/1102902
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568471}
[modify] https://crrev.com/955451dfb49b6cf59dc805737773e944701f9202/chrome/browser/extensions/active_tab_unittest.cc
[modify] https://crrev.com/955451dfb49b6cf59dc805737773e944701f9202/chrome/common/extensions/permissions/permissions_data_unittest.cc
[modify] https://crrev.com/955451dfb49b6cf59dc805737773e944701f9202/extensions/common/permissions/permissions_data.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/81b9fb587c0163a4194868c57394ce49480dc6c2

commit 81b9fb587c0163a4194868c57394ce49480dc6c2
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Wed Jun 20 14:59:46 2018

[Extensions] Enable captureVisibleTab tests for IPv6 URLs

https://crrev.com/c008bf657dbc01fadc4ff1ea3df21f9cf237569a added support
for IPv6 patterns with URLPattern and activeTab, so we can now enable
the tests for captureVisibleTab using IPv6 URLs.

Bug:  839857 
Change-Id: I29eec17b176c54a312cfdf5dc7d11c50b7b245f9
Reviewed-on: https://chromium-review.googlesource.com/1107243
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568842}
[modify] https://crrev.com/81b9fb587c0163a4194868c57394ce49480dc6c2/chrome/browser/extensions/active_tab_unittest.cc
[modify] https://crrev.com/81b9fb587c0163a4194868c57394ce49480dc6c2/chrome/common/extensions/permissions/permissions_data_unittest.cc

I still don't see the "allow capturing file://" option on snipit: https://screenshot.googleplex.com/KoT4WDNUX9M

Is it supposed to be available on 67.0.3396.99 (Official Build) (64-bit)?

Re c#24: That landed in M69 actually. I can make a merge to M68. In the meanwhile a temporary fix to allow the file access setting to show up might be to request host permission to the file scheme as part of optional permissions.

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

I am going to close this out for now, and file a separate bug about capturing the webstore (which I think should potentially be allowed, but is likely less critical).  I'd also like to merge #22 back to M68, since that returns most of the functionality for different pages.  This means that IPv6 URLs won't be included, but I think that's lower priority, and it has a dependency on https://crrev.com/c008bf657dbc01fadc4ff1ea3df21f9cf237569a.

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

c#25 -- many snipit users are complaining about not being able to capture file:// URLs. Yes it'd be great if we can have the option in M68.

Is #22 well tested and is this a safe merge to M68?

@30 I think so, yes.

Approving merge for M68. Branch:3440

Thanks!  Will merge tomorrow morning.

The NextAction date has arrived: 2018-06-29

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2315e7b28b64b2ab562241d57db7c8b227d76709

commit 2315e7b28b64b2ab562241d57db7c8b227d76709
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Sat Jun 30 02:56:59 2018

[Merge M68][Extensions] Update captureVisibleTab permission checks

tabs.captureVisibleTab() is interesting. It used to work with every
URL ever, and just checked for if activeTab or <all_urls> was present.
However, this led to some issues where the extension could capture pages
it shouldn't be able to, such as  https://crbug.com/810220 .

Changing this to only allow access to pages that the extension had
explicit access to also broke important use cases. For instance, taking
screenshots of chrome:-scheme pages is important for filing bugs,
tracking features, etc. This similarly broke use cases for other URLs
that extensions don't have full access to, like other extensions' pages.
An exception was added for chrome:-scheme pages, but this was
insufficient for other cases.

Adjust the permissions check to allow page capture of otherwise-
restricted pages if the extension has activeTab granted. We require
activeTab (rather than either <all_urls> or activeTab) because it gives
a stronger guarantee that the user wants the extension to run on the
given site.

Note: this does not allow any other action on these restricted pages;
only capturing the page is permitted.

The new behavior enforces the following permission requirements for
the host types:
<arbitrary web page>: activeTab OR <all_urls>
file:-scheme page: (activeTab OR <all_urls>) AND
                   explicit file access from chrome://extensions.
Pages restricted by enterprise policy: blocked
Extension's own page: activeTab OR <all_urls>
Another extension's page: activeTab
chrome:-scheme page: activeTab

Support for IPv6 pages and pseudo urls is dependent on these being
properly supported with activeTab, which will be pursued in a followup.

Bug:  839857 

TBR=rdevlin.cronin@chromium.org

(cherry picked from commit 955451dfb49b6cf59dc805737773e944701f9202)

Change-Id: Ied3a71732cd5d41ad16f9b459f6fda9b1815edaf
Reviewed-on: https://chromium-review.googlesource.com/1102902
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#568471}
Reviewed-on: https://chromium-review.googlesource.com/1121380
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#576}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/2315e7b28b64b2ab562241d57db7c8b227d76709/chrome/browser/extensions/active_tab_unittest.cc
[modify] https://crrev.com/2315e7b28b64b2ab562241d57db7c8b227d76709/chrome/common/extensions/permissions/permissions_data_unittest.cc
[modify] https://crrev.com/2315e7b28b64b2ab562241d57db7c8b227d76709/extensions/common/permissions/permissions_data.cc

 Issue 859496  has been merged into this issue.

Replying to c#29: The change is merged to M68.

I give a test on Chrome Dev channel today, and find that captureVisibleTab will fail on "about:blank", would you please check? (It is reported as part of  Issue 859496  which is dealt as duplicate)

The error says as following:
 "Unchecked runtime.lastError: Cannot access contents of url "". Extension manifest must request permission to access this host."

The problem persist if the extension is overriding New tab page - because the tab has actually "chrome://newtab/" URL, not the extension URL.

Can we as part of this bug fix this for "chrome://newtab/" as well?

After this update, active tab will still be able to captureVisibleTab of
chrome://newtab, right?

Thanks for the additional reports, everyone.

#38: I'll update this to allow about:blank, as well.  This will likely land in M69.

#39: That's an interesting case. This should still work with the activeTab permission granted; can you confirm that's the case?  It is a bit interesting that the newtab page is treated differently than other extension pages (where just having <all_urls> is sufficient), though.

#40: Yes, activeTab should allow the extension to capture any chrome:-scheme URL, including chrome://newtab.  Feel free to try this out on Canary/Dev and let me know if you run into issues.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e3abe63770aeb692fab5f1f00f76464af0eeb451

commit e3abe63770aeb692fab5f1f00f76464af0eeb451
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Tue Jul 17 01:47:55 2018

[Extensions Docs] Clarify permission requirements for captureVisibleTab

Add additional details on the permission requirements for the
tabs.captureVisibleTab() method, including that activeTab is required
for sensitive sites that the extension wouldn't otherwise be allowed
access to.

Bug:  839857 
Change-Id: I6fa1a68e8dc50bc7c3553fb32740b4c963276395
Reviewed-on: https://chromium-review.googlesource.com/1138634
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575519}
[modify] https://crrev.com/e3abe63770aeb692fab5f1f00f76464af0eeb451/chrome/common/extensions/api/tabs.json

@41 I don't really have a way to test it with activeTab but I suppose it would work.

The issue here is with the <all_urls> and only if address bar is empty (which is by default if you override new tab page). Because if you navigate to the extension page manually like "chrome-extension://onbnheemmeialopoelmofndfmbkpdmbk/extension.html" then it will work - probably because the URL is for extension, not  "chrome://newtab/".

Also "hotfix" like "chrome.tabs.update({url: 'extension.html'})" won't work - tab URL stays "chrome://newtab/".

Looks like captureVisibleTab() won't work on "view-source:" either anymore? Is it intentional?

This is still not working in Version 69.0.3497.100 (Official Build) (64-bit) for an extension with tabs, activeTab and <all_urls> permissions enabled.

chrome:// pages fail with "The 'activeTab' permission is not in effect because this extension has not been in invoked.", even though user navigation events are registered e.g, click on links and buttons, toggle settings etc.

chrome-devtools:// pages fail with "Cannot access contents of url "chrome-devtools://devtools/". Extension manifest must request permission to access this host."

 Issue 911443  has been merged into this issue.