Closed Bug 1463074 Opened 6 years ago Closed 6 years ago

Web Extension Content Script is not injected to Iframes on background pages

Categories

(WebExtensions :: Frontend, defect, P3)

60 Branch
defect

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
Attached file firefoxbug.zip
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
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
Whiteboard: [design-decision-needed]
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.
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]
Even seems a bug to me. I always thought this worked.
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.
Product: Toolkit → WebExtensions
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: