Closed
Bug 1463074
Opened 7 years ago
Closed 6 years ago
Web Extension Content Script is not injected to Iframes on background pages
Categories
(WebExtensions :: Frontend, defect, P3)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: jktaylo1, Unassigned)
Details
(Keywords: parity-chrome, testcase, Whiteboard: [design-decision-approved])
Attachments
(1 file)
923 bytes,
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Steps to reproduce:
This works fine in chrome, but in my extension manifest I have...
"content_scripts": [
{
"all_frames": true,
....
Actual results:
Nothing
Expected results:
Firefox should inject my content script into the iframe
Updated•7 years ago
|
Component: Untriaged → WebExtensions: Frontend
Keywords: parity-chrome,
testcase
Product: Firefox → Toolkit
Updated•7 years ago
|
Whiteboard: [design-decision-needed]
Comment 1•6 years ago
|
||
Hi jktaylo1, this has been added to the agenda for the WebExtensions APIs triage on May 29, 2018. Would you be able to join us?
Here’s a quick overview of what to expect at the triage:
* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details
Relevant Links:
* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1Y_oYPldTT_kQOOouyJbC-8y3ASIizScLKFRhQfsDQWI/edit#heading=h.v63i1wz9d1pc
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Sounds great Caitlin! I am interested in attending and will definitely be there on Tuesday! I hope it is an easy bug to fix, and I made and attached a simple test case to reproduce.
Comment 3•6 years ago
|
||
Since this is a parity-chrome issue, we should consider whether it needs higher priority.
Flags: needinfo?(mconca)
Priority: -- → P5
Whiteboard: [design-decision-needed] → [design-decision-approved]
Comment 4•6 years ago
|
||
Even seems a bug to me. I always thought this worked.
Updated•6 years ago
|
Flags: needinfo?(mconca)
Priority: P5 → P3
If anyone comes across this and needs a work around since it probably will never be fixed, you can just add an iframe to the current tab and the content script will go in there. Then you can do some work in the iframe and remove it when you are done.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Comment 6•6 years ago
|
||
As of Firefox 63, content scripts appear to run in iframes created in background scripts (as evidenced by this demo add-on: https://github.com/osmose/webext-iframe-content-script). There seems to be other weird behavior restrictions though; I can't receive messages from the background script sent of a port.
Comment 7•6 years ago
|
||
It seems that content scripts are injecting just fine in Firefox 61 and 63.
When I load the test case and change console.log to fetch("http://localhost/"), then I see that the script runs as expected.
console.log doesn't appear, but that is probably related to out-of-process extensions.
When I run with extensions.webextensions.remote=false, then the log is shown. When I run with the flag set to true (default on all platforms, on Linux since Firefox 63), the log message is not shown.
(In reply to Michael Kelly [:mkelly,:Osmose] from comment #6)
> As of Firefox 63, content scripts appear to run in iframes created in
> background scripts (as evidenced by this demo add-on:
> https://github.com/osmose/webext-iframe-content-script). There seems to be
> other weird behavior restrictions though; I can't receive messages from the
> background script sent of a port.
See bug 1488105.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•