browser.tabs.executeScript(..., {allFrames: true}) with activeTab permission is unable to inject into iframes on the page.
Categories
(WebExtensions :: General, defect)
Tracking
(firefox86 affected)
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | affected |
People
(Reporter: micah, Unassigned)
References
Details
Attachments
(1 file)
|
1.01 KB,
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
The following files are available in attached .zip file.
manifest.json
{
"name": "allframes injection failure repro",
"version": "0.0.1",
"manifest_version": 2,
"description": "Shows the problem with activeTab injection into iframes",
"homepage_url": "https://example.com",
"background": {
"scripts": [
"background.js"
]
},
"browser_action": {
"default_title": "Inject!"
},
"permissions": [
"activeTab"
]
}
background.js
browser.browserAction.onClicked.addListener(tab => {
browser.tabs.executeScript(tab.id, { file: 'inject.js', allFrames: true })
})
inject.js
console.log(`Injected into ${window.location}`)
index.html
<body>
<main>Index</main>
<iframe src='http://www.guimp.com/'></iframe>
</body>
Load manifest.json as a browser add-on and serve index.html as a static site via the means of your choosing.
Once loaded, click on the add-on.
Actual results:
Only one line is logged, Injected into http://localhost:8081 (exact text may differ depending on your mechanism of serving the page).
Expected results:
Two lines should be logged:
Injected into http://localhost:8081/
Injected into http://www.guimp.com/
Note: Adding the permission <all_urls> resolves the problem, but requires the extension be given basically all access to all user data which is very much against the general goal of privacy and security that Firefox tries to achieve.
|
Reporter | |
Comment 1•5 years ago
|
||
I suspect that the issue is that activeTab merely gives permission for window.location of the active tab, and the iframe (which is a cross-site iframe) wouldn't be included in the set of URLs that the extension has permission to touch. However, I think the user expectation here is that activeTab means "I am OK with this extension interacting with everything in this browser tab", which would include iframes and the like.
As a developer, I don't want to require my user give me 100% access to everything they do in the browser. I only want to be given access when they need the features of the extension, which is determined by user activation of the extension via click. Once they click though, I need the ability to actually affect the whole tab they activated the extension on, including iframes. Since I cannot inject a script into a top level page and then touch an iframe from there, I have to inject into each iframe in order to touch them (which is what the user has requested I do).
|
|
Reporter | |
Comment 2•5 years ago
|
||
Related Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=826433
|
||
Comment 3•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 4•5 years ago
|
||
Hello,
I’ve managed to reproduce the issue only on the latest Nightly (86.0a1/20210104172545). Also tested with the latest Beta (85.0b4/20201220193140) and Release (84.0.1/20201221152838) under Windows 10 x64, serving index.html via a python http sever on port 8000.
Only on Nightly did the web console display that one single line “Injected into http://localhost:8000/” as opposed to Beta and Release where both lines were displayed (Injected into http://localhost:8000/,
Injected into http://www.guimp.com/)
|
|
Reporter | |
Comment 5•5 years ago
|
||
Hmm, you being unable to reproduce the issue in latest release is surprising to me. I am running on 84.0.1 normal release on Windows, downloaded from Firefox homepage and updated through auto-updater. Is there perhaps a setting you or I might have set that would make us experience different behavior in the latest release version?
|
|
Reporter | |
Comment 6•5 years ago
|
||
Just to rule it out, did you perhaps test first on nightly, then add <all_urls> to the manifest.json, then test on beta and release using that already modified manifest.json? That would make it reproduce only on nightly but not reproduce on beta or release.
|
|
||
Comment 7•5 years ago
•
|
||
I'm running the latest normal Release as you are, with maybe the slight difference that I launch Firefox with the profile manager and always test scenarios on a clean profile. Same for Beta and Nightly.
And to reply to Comment 6, I did not touch the manifest.json at all. I loaded it in the same state you provided it in.
I'll keep looking into this and post here any results I find. Though unlikely, as I went through the reproduction steps very carefully, I might have made a mistake somewhere.
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 8•5 years ago
|
||
Clearing Fission Milestone flag because this doesn't look like a Fission bug.
|
||
Comment 9•3 years ago
|
||
I cannot reproduce this on the latest Firefox Nightly (111.0a1) - i.e. the expected results occur.
Note that the "expected" behavior is unique to Firefox and MV2; all other browsers only grant access to the top-level origin.
In MV3, only the top-level origin is granted when activeTab is used (bug 1781801).
Description
•