Closed Bug 1061285 Opened 10 years ago Closed 2 years ago

Cannot uniquely address content script depending on the context that loaded it.

Categories

(Core :: DOM: Content Processes, defect, P5)

34 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: pjs.nl, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140825202822

Steps to reproduce:

Identical content scripts which are shared between different extensions and hence might be of different versions cannot be uniquely addressed depending on the context that loaded it, thus making content script code re-use impossible.


Actual results:

Content scripts with identical interfaces (but potentially different implementations) respond to messages from all extensions that share (versions of) the same content script.


Expected results:

Content scripts should be uniquely addressable using a key which depends on the context that loaded it (unique for each extension and each extension re-installation(!)), using for example:

load_context_key = loadFrameScript(path);
sendAsyncMessage(load_context_key + ":name@origin:" + message);

The message dispatching mechanism cannot be implemented by extension developers and should be done by the application (otherwise the version issue re-appears for the message dispatcher itself).

Ideally, the implementation (and unique key) would be completely hidden from the (extension) developer in order to always make content scripts addressable only by the (extension) context that loaded it (what is against this?). The same unique key could be used to solve the current content script caching issue. This approach would significantly improve the safety of content script usage.
Potential workaround: load the frame script with a data uri, add a unique ID inside the data uri and then load whatever script you need with a script loader and make the unique ID available to it.
The previous comment and hints from Kris Maglione and Wladimir Palant 
helped me to find the following workaround for the above-mentioned issues:

1) Substitute the extension id for the resource path in "bootstrap.js":
        Rp.setSubstitution(id, ext.resourceURI);
2) Load a frame script "bootframe.js" from the resource path:
        path = "resource://" + id + "/bootframe.js";
        rnd = "?" + Math.random().toString().replace(/\./g, "");
        mm.loadFrameScript(path + rnd, true);
3) In "bootframe.js", retrieve the "id", "path" and "rnd" strings as follows:
        file = Components.stack.filename;
        id = file.split(/\//g)[2];
        path = "resource://" + id + "/";
        rnd = "?" + file.split(/\?/g)[1];
4) Append the "rnd" string to all message names in order to restrict access.
5) Inject the "id" and/or "rnd" strings into any modules loaded from "path".
Priority: -- → P5

Frame scripts are going away, so I don't think we're going to do anything here.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.