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)
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.
Reporter | ||
Comment 2•10 years ago
|
||
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".
Updated•6 years ago
|
Priority: -- → P5
Comment 3•2 years ago
|
||
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.
Description
•