content/worker does not work for top-level windows in firefox38+

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: nekr, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36

Steps to reproduce:

Create extensions which opens top-level window via sdk/window/utils#open and attach via sdk/content/worker#Worker. See example here: http://pastebin.com/neRC6wBi




Actual results:

getFrameElement(...) is null in firefox38
frame is null in firefox39


Expected results:

Worker should be attached to windows as in firefox36-37
(Reporter)

Comment 1

4 years ago
I understand what that API is "Unstable", but do you have other way to attach worker to such window?
If you use sdk/deprecated/sync-worker it should work as it used to but as the name suggests that mechanism is deprecated for now. I wasn't aware of any use for attaching workers to top-level windows, what are you using it for?
(Reporter)

Comment 3

4 years ago
In my case it requires permission to access remote host via XHR. I declared that access for content scripts in package.json and to archive it in panel document and that window document I did not used regular <script> tags for those document, but only content scripts. It worked okay in 36/37 and it would be good to have it worked in newer version with e10n. For now I just attached sandbox with system principals to that window.
I'm sorry but, attaching content/workers to top levels windows is just not something that this module was designed for.

We'd need to have a pretty good reason to implement that, and so far have not had any.  If you have one please describe it and re-open if you think this is necessary for you.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.