Issue metadata
Sign in to add a comment
|
Allow users to toggle file access for extensions with activeTab.
Reported by
peter.m....@gmail.com,
Jun 7 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36 Steps to reproduce the problem: 1. Have Chrome v67 installed 2. Grab this extension https://github.com/mrcoles/test-chrome-extension-executescript-local-file - pack it in chrome://extensions - and drag it onto chrome to install (or just drag the attached .crx onto chrome) 3. Run the extension on any local HTML file on your computer, e.g., bash -c 'echo \'<html><body>TEST PAGE</body></html>\' > test.html && open test.html' What is the expected behavior? The extension does executeScript. It should succeed and the popup should say, “Did it work? YES!” What went wrong? The executeScript call encounters a `chrome.runtime.lastError` of: > Cannot access contents of the page. Extension manifest must request permission to access the respective host. Did this work before? Yes 66 Does this work in other browsers? N/A Chrome version: 67.0.3396.79 Channel: stable OS Version: OS X 10.13.2 Flash Version: This was first reported by various folks using the beta version of Chrome and I have since reproduced it after updating. There is also a vague reference in some extensions of enable “access to local files” from chrome://extensions, but I cannot find documentation on this nor do I see it as an option anywhere. What is that?
,
Jun 7 2018
@thakis - regarding marking this as a duplicate, it is important to note that: 1. The issue from the other bug with `chrome.tabs.captureVisibleTab` fails for all extensions (packed or unpacked) 2. This issue in this bug with `chrome.tabs.executeScript` on local files only fails for packed extensions I would hate for only the `captureVisibleTab` fix to come through and for this one to get ignored.
,
Jun 7 2018
Yeah, this isn't really a duplicate of 839857. As background, extensions require explicit permission to be able to run on file:// URLs. This permission is granted from the chrome://extensions page (on the details page for an extension, there's an "Allow access to file URLs" toggle that the user has to enable). However, there's a bug in this. More on that later. Previously, activeTab granted temporary file access if the extension was invoked on a tab open to a file:// url. This was changed in revision 7a33a5423fd1e6beab05c08cae24a6fc9dee2999, since it was at odds with the setting the user had in chrome://extensions. Now, the extension must explicitly have file access to run on file:// URLs, whether or not it has activeTab granted. This was a desired change, but means that active tab is no longer sufficient. I looked around our documentation, and agree that this is woefully absent - nowhere do we seem to describe how an extension can run on file URLs. We have a very brief allusion to it here [0], but it's very incomplete. That's definitely something we should fix - +crystallambert@. The reason this works for unpacked extensions is that unpacked extensions are auto-granted file access. This was a decision made some time ago (many years back), that we've been rethinking. It's undecided if we'll change it yet. So, back to the bug for the "Allow access to file URLs" toggle. We currently only show this in the extension page if the extension "wants file access" or has it as an unpacked extension (and we don't show it for policy-installed extensions, but that's neither here nor there). [1] An extension "wants file access" if it has a content script [2] or host permission [3] that matches the file scheme, such as "file://*/*" or "<all_urls>" (note: "*://*/*" only matches http/https). This means that extensions with activeTab won't want file access, and there's no way to enable it for them, which is bad. At minimum, we should: - Add better/more complete documentation for file access. It doesn't have to be extreme (a paragraph or two would be sufficient), but we should have it somewhere. I'll file a separate bug for this. - Ensure that activeTab results in an extension "wanting file access", so that the control shows up in chrome://extensions. karandeepb@, can you handle this? [0] https://developer.chrome.com/extensions/extension#method-isAllowedFileSchemeAccess [1] https://chromium.googlesource.com/chromium/src/+/31b51b0dc71d3cae17391a1246998241bfcfdbd8/chrome/browser/extensions/api/developer_private/extension_info_generator.cc#403 [2] https://chromium.googlesource.com/chromium/src/+/0635a5ef1c7493c7ec3477587978c05a03af982a/extensions/common/manifest_handlers/content_scripts_handler.cc#184 [3] https://chromium.googlesource.com/chromium/src/+/0635a5ef1c7493c7ec3477587978c05a03af982a/extensions/common/manifest_handlers/permissions_parser.cc Thanks for filing the bug, peter.m.coles@!
,
Jun 7 2018
Filed issue 850693 to track adding better documentation for this.
,
Jun 7 2018
>> Ensure that activeTab results in an extension "wanting file access", so that the control shows up in chrome://extensions. karandeepb@, can you handle this? Will look into this. Haven't verified this, but 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.
,
Jun 8 2018
rdevlin@, thank you for the thorough response. I tried adding the following to the manifest of the example repo, packed it, ran it, and was able to verify that it gave an option to allow access to files from the extensions page (without having to explicitly request file access): > "optional_permissions": [ "file://*/*"] So, at least, I see a way forward to supporting this (1) with the ability to get that option to show up and (2) without having to aggressively ask for permissions to all files. However, it’s really frustrating to have this change from underneath my feet. The updated documentation would be greatly appreciated.
,
Jun 8 2018
Separately, is there any way of detecting that the extension needs “Allow access to file URLs” enabled other than trying to `executeScript` and reacting to a failure?
,
Jun 8 2018
@7 Any interaction with file:// URLs should require explicit file access, so if the extension has the "tabs" permission, this is easy to check. With activeTab, I would envision something like:
chrome.browserAction.onClicked.addListener(function(tab) {
if (new URL(tab.url).protocol === 'file:') {
chrome.extension.isAllowedFileSchemeAccess(function(allowed) {
if (!allowed) {
// Signal failure somehow - notification, updating icon, etc.
} else {
// Inject
}
});
} else {
// Inject
}
});
(Obviously, this is rough, and just for illustrative purposes - real extensions should optimize, cache the isAllowedFileSchemeAccess value, etc.)
Would that work for you?
,
Jun 11 2018
,
Jun 11 2018
,
Jun 12 2018
@8 - thank you, that snippet helped a lot
,
Jun 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/396ced81d62743154629327f121a407db5969e49 commit 396ced81d62743154629327f121a407db5969e49 Author: Karan Bhatia <karandeepb@chromium.org> Date: Tue Jun 12 22:38:56 2018 Extensions: Show file access toggle for activeTab extensions. r548269 disallowed implicit file url access for extensions with activeTab. This CL ensures that the file access toggle is visible for extensions using the activeTab permission, hence providing a way for these extensions to be used on file urls. BUG= 850643 TEST=Install an extension with activeTab permission. (E.g. https://chrome.google.com/webstore/detail/page-redder/difbeimhegehkihppkgdlpongficimep?hl=en). Ensure that "Allow access to file URLs" checkbox is shown for the extension. Change-Id: I777c8edb29666343f2e5a6e7a1a06a32746178a8 Reviewed-on: https://chromium-review.googlesource.com/1096352 Commit-Queue: Karan Bhatia <karandeepb@chromium.org> Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org> Cr-Commit-Position: refs/heads/master@{#566610} [modify] https://crrev.com/396ced81d62743154629327f121a407db5969e49/chrome/browser/extensions/api/developer_private/extension_info_generator_unittest.cc [modify] https://crrev.com/396ced81d62743154629327f121a407db5969e49/extensions/common/manifest_handlers/permissions_parser.cc
,
Jun 12 2018
,
Jun 26 2018
Requesting merge of CL in c#12 to M68.
,
Jun 26 2018
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
,
Jun 28 2018
Can you please comment on why this is critical for M68? My preference is to wait until M69.
,
Jun 29 2018
We landed a change in M67 (https://crrev.com/7a33a5423fd1e6beab05c08cae24a6fc9dee2999) that changed how the activeTab permission behaved on file urls, without providing an easy way for users to override that through extension settings. There have been some complaints regarding it (See https://bugs.chromium.org/p/chromium/issues/detail?id=839857#c29). I won't consider it critical for M68, but it's nice to have. The change should be safe.
,
Jul 3
Approving merge to M68. Seems like a small and safe fix, and been in canary for over 2 weeks. Branch:3440
,
Jul 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ef03c32e406c3149a82a2fc85f70b9d4d6c412ec commit ef03c32e406c3149a82a2fc85f70b9d4d6c412ec Author: Karan Bhatia <karandeepb@chromium.org> Date: Tue Jul 03 20:32:46 2018 [Merge M68] Extensions: Show file access toggle for activeTab extensions. r548269 disallowed implicit file url access for extensions with activeTab. This CL ensures that the file access toggle is visible for extensions using the activeTab permission, hence providing a way for these extensions to be used on file urls. BUG= 850643 TEST=Install an extension with activeTab permission. (E.g. https://chrome.google.com/webstore/detail/page-redder/difbeimhegehkihppkgdlpongficimep?hl=en). Ensure that "Allow access to file URLs" checkbox is shown for the extension. TBR=rdevlin.cronin@chromium.org Change-Id: I777c8edb29666343f2e5a6e7a1a06a32746178a8 Reviewed-on: https://chromium-review.googlesource.com/1096352 Commit-Queue: Karan Bhatia <karandeepb@chromium.org> Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#566610}(cherry picked from commit 396ced81d62743154629327f121a407db5969e49) Reviewed-on: https://chromium-review.googlesource.com/1124909 Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Cr-Commit-Position: refs/branch-heads/3440@{#595} Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733} [modify] https://crrev.com/ef03c32e406c3149a82a2fc85f70b9d4d6c412ec/chrome/browser/extensions/api/developer_private/extension_info_generator_unittest.cc [modify] https://crrev.com/ef03c32e406c3149a82a2fc85f70b9d4d6c412ec/extensions/common/manifest_handlers/permissions_parser.cc
,
Jul 3
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by thakis@chromium.org
, Jun 7 2018Status: Duplicate (was: Unconfirmed)