activeTab does not enable scripting.executeScript to execute in iframe with different origin
Categories
(WebExtensions :: General, task, P3)
Tracking
(Not tracked)
People
(Reporter: vasvir2, Unassigned)
References
Details
(Keywords: dev-doc-needed, Whiteboard: [wecg])
Attachments
(1 file)
|
92.43 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0
Steps to reproduce:
I am developing an extension: https://github.com/vasvir/gwt-sdm-compile
The extension needs to run a content script during popup in order to scan the page and its iframes.
When the iframe is from a different origin then the content function is not loaded and not run.
In order to test it you need to bring the iframe in the above page. So you need to click the blue biblio link in one of the two lines and then to click the extension icon to bring the popup.
Actual results:
In firefox it brings only one line, the one of the main window.
Expected results:
In chrome it works and populates the table with two lines as it shoud
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Reporter | ||
Comment 2•3 years ago
|
||
No the bot got it wrong. This is a WebExtension V3 bug.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
While a user can generally see the tab on which the extension is acting, they cannot easily know the source of the iframes.
For this reason, we decided to made the activeTab behavior stricter in MV3 (bug 1774642).
The current alternative is for the extension to request <all_urls>, but that is far more dangerous/scary than just the activeTab permission.
I would very much be in favor of a way to grant access to all content on the current page, e.g. an activeTabAndFrames permission.
This exact use case/missing feature is also tracked on the Chromium side at https://bugs.chromium.org/p/chromium/issues/detail?id=826433
| Reporter | ||
Comment 4•3 years ago
|
||
If I request '<all_urls>' along with ActiveTab, tabs in permissions: See below what I get.
In host_permissions I already have <all_urls>.
Maybe I am putting the <all_urls> to the wrong place?
Thanks.
In Chrome:
Permission '<all_urls>' is unknown or URL pattern is malformed.
In Firefox:
Reading manifest: Warning processing permissions: Error processing permissions.5: Value "<all_urls>" must either: must either [must either [be one of ["idle"], be one of ["menus.overrideContext"], be one of ["search"], be one of ["activeTab"], be one of ["cookies"], be one of ["scripting"], or be one of ["webRequest", "webRequestBlocking", "webRequestFilterResponse", "webRequestFilterResponse.serviceWorkerScript"]], must either [be one of ["mozillaAddons"], be one of ["normandyAddonStudy"], be one of ["urlbar"], be one of ["activityLog"], be one of ["networkStatus"], or be one of ["telemetry"]], be one of ["alarms", "storage", "unlimitedStorage"], be one of ["captivePortal"], be one of ["identity"], be one of ["menus", "contextMenus"], be one of ["geckoProfiler"], be one of ["contextualIdentities"], be one of ["dns"], be one of ["declarativeNetRequestWithHostAccess"], or be one of ["theme"]], must either [must either [be one of ["idle"], be one of ["menus.overrideContext"], be one of ["search"], be one of ["activeTab"], be one of ["cookies"], be one of ["scripting"], or be one of ["webRequest", "webRequestBlocking", "webRequestFilterResponse", "webRequestFilterResponse.serviceWorkerScript"]], be one of ["clipboardRead", "clipboardWrite", "geolocation", "notifications"], be one of ["browsingData"], be one of ["bookmarks"], be one of ["devtools"], be one of ["find"], be one of ["history"], be one of ["pkcs11"], be one of ["sessions"], be one of ["tabs", "tabHide"], be one of ["topSites"], be one of ["browserSettings"], be one of ["declarativeNetRequestFeedback"], be one of ["downloads", "downloads.open"], be one of ["management"], be one of ["privacy"], be one of ["proxy"], be one of ["nativeMessaging"], or be one of ["webNavigation"]], be one of ["declarativeNetRequest"], or match the pattern /^experiments(.\w+)+$/
Comment 5•3 years ago
|
||
It should be in host_permissions. Here is a code example that fits well in your existing code: https://github.com/mdn/webextensions-examples/tree/main/dnr-redirect-url
| Reporter | ||
Comment 6•3 years ago
|
||
Thanks but I already have it there: See: https://github.com/vasvir/gwt-sdm-compile/blob/main/manifest.json
Maybe another bug? Or I did something horribly wrong?
Comment 7•3 years ago
|
||
Please read the README and the popup.html + popup.js files. In particular this part is relevant to you:
Redirecting requires host permissions for the pre-redirect URLs. In Firefox (and Safari), Manifest V3 extensions do not have access to these by default. The permission to these can be granted from the extension action popup.
| Reporter | ||
Comment 8•3 years ago
|
||
Thank you very much. The information and the example you pointed me to worked great.
I suppose since this is the intended behavior it is not actually a bug.
Maybe it should be listed as a documentation task?
Is there a product/component in this bugzilla instance for documentation?
Anyway thanks again. It would be impossible to find this on my own.
Vassilis
Comment 9•3 years ago
|
||
Ideally the extension wouldn't need access to all URLs, but if we end up accepting that behavior across browsers, then this would indeed be a documentation task only.
Updated•3 years ago
|
Comment 10•3 years ago
|
||
The severity field is not set for this bug.
:zombie, could you have a look please?
For more information, please visit BugBot documentation.
| Reporter | ||
Comment 11•3 years ago
|
||
For future reference and for any poor soul that is trying to get this working:
The request of the new permission needs to be done by a user initiated callback like a button click handler.
Comment 12•3 years ago
|
||
(In reply to Rob Wu [:robwu] from comment #9)
Ideally the extension wouldn't need access to all URLs, but if we end up accepting that behavior across browsers, then this would indeed be a documentation task only.
Let's document this for now. If we decide in WECG to introduce an enhancement, that will probably be a separate bug.
Updated•3 years ago
|
Description
•