I would like to use the Web Worker facility introduced in Firefox 3.5 to enhance a Greasemonkey script I'm working on.
Is this even possible?
I've done some experimentation, but I can't get past the issue of loading a worker script from an arbitrary domain.
For example, this does not work:
var myWorker = new Worker("http://dl.getdropbox.com/u/93604/js/worker.js");
This code generates an error message in my Firebug console:
Failed to load script:
http://dl.getdropbox.com/u/93604/js/worker.js
(nsresult = 0x805303f4)
Apparently there's a limitation that does not allow you to start a worker from a URL that's not relative to the base URL of the calling script. You can load a worker script at a relative URL like this just fine:
var myWorker = new Worker("worker.js");
But there's no way for me to get the worker script on the user's filesystem so that it could be at a path relative to the calling script.
Am I screwed here? Should I give up on trying to use workers within my Greasemonkey script?
For years I thought it wasn't possible to use web workers in GM. Of course the first idea was to use data-urls. But the Worker constructor didn't seem to accept them.
Today I tried it again and it worked without any problems at first. Only when I started to use functions of the GM API the Worker constructor stopped working.
Seemingly Firefox has a bug that prevents you from accessing Worker from a sandbox with X-ray vision. Even evaluating typeof Worker throws an exception. So the only way to use workers is to get the unwrapped version from the unwrapped window:
var echoWorker = new unsafeWindow.Worker("data:text/javascript," +
"self.onmessage = function(e) {\n" +
" self.postMessage(e.data);\n" +
"};"
);
Of course you have to be careful about special characters. It's better to encode the script with base64:
var dataURL = 'data:text/javascript;base64,' + btoa(script);
var worker = unsafeWindow.Worker(dataURL);
Alternatively you can also use blob-urls:
var blob = new Blob([script], {type: 'text/javascript'});
var blobURL = URL.createObjectURL(blob);
var worker = new unsafeWindow.Worker(blobURL);
URL.revokeObjectURL(blobURL);
If you really want to use a script hosted on a different domain that's not a problem because same origin policy doesn't apply for GM_xmlhttpRequest:
function createWorkerFromExternalURL(url, callback) {
GM_xmlhttpRequest({
method: 'GET',
url: url,
onload: function(response) {
var script, dataURL, worker = null;
if (response.status === 200) {
script = response.responseText;
dataURL = 'data:text/javascript;base64,' + btoa(script);
worker = new unsafeWindow.Worker(dataURL);
}
callback(worker);
},
onerror: function() {
callback(null);
}
});
}
By now (10 years later), it's possible to use Web Workers with Firefox 77 and Tampermonkey. I've tested sucessfully using inline workers:
var blob = new Blob(["onmessage = function(e){postMessage('whats up?');console.log(e.data)}"], {type: 'text/javascript'})
var url = URL.createObjectURL(blob)
var worker = new Worker(url)
worker.onmessage = function(e){
console.log(e.data)
}
worker.postMessage('hey there!')
With Chrome or other extension like Greasemonkey ou Violentmonkey, i'ts not working because of CSP worker-src (see violation cases at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src). This is why is not possible to use HTTP URLs or string as argument of Worker constructor, only works with blob URLs in this very specific case.
Still, there is a catch about the context of Workers. They can't access DOM, window, document or parent objects (see features available to workers at https://www.html5rocks.com/en/tutorials/workers/basics/).
See:
Can I load a web worker script from an absolute URL?
Related
I have a page which will normally overrides window.XMLHttpRequest with a wrapper that does a few extra things like inserting in headers on certain requests.
I have some functionality in a 3rd party library that uses HTML5 Worker, and we are seeing that this request does not use the XMLHttpRequest wrapper object. So any request that this library makes is missing the required headers, and so the request will fail.
Is there a way to control the XMLHttpRequest that any Worker the current thread creates?
This 3rd party library code looks like this:
function createWorker(url) {
var worker = new Worker(url);
worker.onmessage = function (e) {
if (e.data.status) {
onprogress(e.data.status);
} else if (e.data.error) {
onerror(e.data.error);
} else {
exportUtils.saveFile(new Blob([e.data]), params.fileName);
onfinish();
}
};
worker.postMessage(params); // window.location.origin +
return worker;
}
The Javascript that is returned by the URL variable above contains code like this:
return new Promise(function(t, r) {
var n = new XMLHttpRequest
, a = "batch_" + o()
, u = e.dataUrl.split(e.serviceUrl)[1]
, c = [];
n.onload = function() {
for (var e = this.responseText, n = this.responseText.split("\r\n"), o = 0, a = n.length, i = a - 1; o < a && "{" !== n[o].slice(0, 1); )
o++;
for (; i > 0 && "}" !== n[i].slice(-1); )
i--;
n = n.slice(o, i + 1),
e = n.join("\r\n");
try {
var u = JSON.parse(e);
t(u)
} catch (t) {
r(s + e)
}
}
,
n.onerror = function() {
r(i)
}
,
n.onabort = function() {
r(i)
}
,
n.open("POST", e.serviceUrl + "$batch", !0),
n.setRequestHeader("Accept", "multipart/mixed"),
n.setRequestHeader("Content-Type", "multipart/mixed;boundary=" + a);
for (var p in e.headers)
"accept" != p.toLowerCase() && n.setRequestHeader(p, e.headers[p]);
c.push("--" + a),
c.push("Content-Type: application/http"),
c.push("Content-Transfer-Encoding: binary"),
c.push(""),
c.push("GET " + u + " HTTP/1.1");
for (var p in e.headers)
c.push(p + ":" + e.headers[p]);
c.push(""),
c.push(""),
c.push("--" + a + "--"),
c.push(""),
c = c.join("\r\n"),
n.send(c)
}
)
The answer is both a soft "no" and an eventual "yes".
When a piece of code runs in a different context (like a webworker or an iframe), you do not have direct control of its global object (1).
What's more, XMLHttpRequest isn't the only way to send out network requests - you have several other methods, chief among them the fetch api.
However, there's a relatively new kid in block called Service Workers which can help you quite a bit!
Service workers
Service workers (abbrev. SWs) are very much like the web workers you already know, but instead of only running in the current page, they continue to run in the background as long as your user stays in your domain. They are also global to your entire domain, so any request made from your site will be passed through them.
Their main purpose in life is reacting to network requests, usually used for caching purposes and offline content, serving push notifications, and several other niche uses.
Let's see a small example (note, run these from a local webserver):
// index.html
<script>
navigator.serviceWorker.register('sw.js')
.then(console.log.bind(console, 'SW registered!'))
.catch(console.error.bind(console, 'Oh nose!'));
setInterval(() => {
fetch('/hello/');
}, 5000);
</script>
// sw.js
console.log('Hello from a friendly service worker');
addEventListener('fetch', event => {
console.log('fetch!', event);
})
Here we're registering a service worker and then requesting a page every 5 seconds. In the service worker, we're simple logging each network event, which can be caught in the fetch event.
On first load, you should see the service worker being registered. SWs only begin intercepting requests from the first page after they were installed...so refresh the page to begin seeing the fetch events being logged. I advise you to play around with the event properties before reading on so things will be clearer.
Cool! We can see from poking around with the event in the console that event.request is the Request object our browser constructed. In an ideal world, we could access event.request.headers and add our own headers! Dreamy, isn't it!?
Unfortunately, request/response headers are guarded and immutable. Fortunately, we are a stubborn bunch and can simply re-construct the request:
// sw.js
console.log('Hello from a friendly service worker');
addEventListener('fetch', event => {
console.log('fetch!', event);
// extract our request
const { request } = event;
// clone the current headers
const newHeaders = new Headers();
for (const [key, val] of request.headers) {
newHeaders.append(key, val);
}
// ...and add one of our own
newHeaders.append('Say-What', 'You heard me!');
// clone the request, but override the headers with our own
const superDuperReq = new Request(request, {
headers: newHeaders
});
// now instead of the original request, our new request will take precedence!
return fetch(superDuperReq);
});
This is a few different concepts at play so it's okay if it takes more than once to get. Essentially though, we're creating a new request which will be sent in place of the original one, and setting a new header! Hurray!
The Bad
Now, to some of the downsides:
Since we're hijacking every single request, we can accidentally change requests we didn't mean to and potentially destroy the entire universe!
Upgrading SWs is a huge pain. SW lifecycle is complex, debugging it on your users is difficult. I've seen a good video on dealing with it, unfortunately can't find it right now, but mdn has a fairly good description
Debugging SWs is often a very annoying experience, especially when combined with their weird lifecycles
Because they are so powerful, SWs can only be served over https. You should already be using https anyway, but this is still a hindrance
This is a lot of things to do for a relatively small benefit, so maybe reconsider its necessity
(1) You can access the global object of an iframe in the same origin as you, but getting your code to run first to modify the global object is tricky indeed.
I'm toying with adding web push notifications to a web app hosted with apps script. To do so, I need to register a service worker and I ran into an error with a cross-domain request. Raw content is hosted from *.googleusercontent.com while the script URL is script.google.com/*.
I was able to successfully create an inline worker using this post on creating inline URLs created from a blob with the script. Now I'm stuck at the point of registering the worker in the browser.
The following model works:
HTML
<!-- Display the worker status -->
<div id="log"></log>
Service Worker
<script id="worker" type="javascript/worker">
self.onmessage = function(e) {
self.postMessage('msg from worker');
};
console.log('[Service Worker] Process started');
})
</script>
Inline install
<script>
function log(msg) {
var fragment = document.createDocumentFragment();
fragment.appendChild(document.createTextNode(msg));
fragment.appendChild(document.createElement('br'));
document.querySelector("#log").appendChild(fragment);
}
// Create the object with the script
var blob = new Blob([ document.querySelector("#worker").textContent ]);
// assign a absolute URL to the obejct for hosting
var worker = new Worker(window.URL.createObjectURL(blob));
worker.onmessage = function(e) {
log("Received: " + e.data);
}
worker.postMessage('start');
// navigator.serviceWorker.register(worker) this line fails
</script>
navigator.serviceWorker.register(worker); returns a 400: Bad HTTP response code error.
Can inline workers be installed? Or do all installed workers have to come from external scripts?
It's worth noting that Web Workers and Service Workers, which are used with push notifications, are different (see this SO response to read about the difference).
According to MDN Service Workers require a script URL. In Google Apps Script you could serve a service worker file with something like:
function doGet(e) {
var file = e.parameter.file;
if (file == 'service-worker.js'){
return ContentService.createTextOutput(HtmlService.createHtmlOutputFromFile('service-worker.js').getContent())
.setMimeType(ContentService.MimeType.JAVASCRIPT);
} else {
return HtmlService.createHtmlOutputFromFile('index');
}
}
But as in this example (source code here) because of the way web apps are served you'll encounter the error:
SecurityError: Failed to register a ServiceWorker: The script resource is behind a redirect, which is disallowed.
There was a proposal for Foreign Fetch for Service Workers but it's still in draft.
I managed to get a Web Worker (not a content/worker) in my Firefox add-on using the Add-on SDK. I followed Wladimir's advice here to get the Worker class working: Concurrency with Firefox add-on script and content script
Now, I can launch a worker in my code and can talk to it by sending/receiving messages.
This is my main.js file:
// spawn our log reader worker
var worker = new Worker(data.url('log-reader.js'));
// send and respond to some dummy messages
worker.postMessage('halo');
worker.onmessage = function(event) {
console.log('received msg from worker: ' + event.data);
};
This is my log-reader.js file:
// this function gets called when main.js sends a msg to this worker
// using the postMessage call
onmessage = function(event) {
var info = event.data;
// reply back
postMessage('hey addon, i got your message: ' + info);
if (!!FileReaderSync) {
postMessage('ERROR: FileReaderSync is not supported');
} else {
postMessage('FileReaderSync is supported');
}
// var reader = new FileReaderSync();
// postMessage('File contents: ' + reader.readAsText('/tmp/hello.txt'));
};
My problem is that the FileReaderSync class is not defined inside the log-reader.js file, and as a result I get the error message back. If I uncomment the last lines where FileReaderSync is actually used, I will never get the message back in my addon.
I tried using the same trick I used for Worker, by creating a dummy.jsm file and importing in main.js, but FileReaderSync will only be available in main.js and not in log-reader.js:
// In dummy.jsm
var EXPORTED_SYMBOLS=["Worker"];
var EXPORTED_SYMBOLS=["FileReaderSync"];
// In main.js
var { Worker, FileReaderSync } = Cu.import(data.url('workers.jsm'));
Cu.unload(data.url("workers.jsm"));
I figure there has to be a solution since the documentation here seems to indicate that the FileReaderSync class should be available to a Web Worker in Firefox:
This interface is only available in workers as it enables synchronous I/O that could potentially block.
So, is there a way to make FileReaderSync available and usable in the my Web Worker code?
Actually, your worker sends "ERROR" if FileReaderSync is defined since you negated it twice. Change !!FileReaderSync to !FileReaderSync and it will work correctly.
I guess that you tried to find the issue with the code you commented out. The problem is, reader.readAsText('/tmp/hello.txt') won't work - this method expects a blob (or file). The worker itself cannot construct a file but you can create it in your extension and send to the worker with a message:
worker.postMessage(new File("/tmp/hello.txt"));
Note: I'm not sure whether the Add-on SDK defines the File constructor, you likely have to use the same trick as for the Worker constructor.
The worker can then read the data from this file:
onmessage = function(event)
{
var reader = new FileReaderSync();
postMessage("File contents: " + reader.readAsText(event.data));
}
I'm using the Firefox Addon SDK to build something that monitors and displays the HTTP traffic in the browser. Similar to HTTPFox or Live HTTP Headers. I am interested in identifying which tab in the browser (if any) generated the request
Using the observer-service I am monitoring for "http-on-examine-response" events. I have code like the following to identify the nsIDomWindow that generated the request:
const observer = require("observer-service"),
{Ci} = require("chrome");
function getTabFromChannel(channel) {
try {
var noteCB= channel.notificationCallbacks ? channel.notificationCallbacks : channel.loadGroup.notificationCallbacks;
if (!noteCB) { return null; }
var domWin = noteCB.getInterface(Ci.nsIDOMWindow);
return domWin.top;
} catch (e) {
dump(e + "\n");
return null;
}
}
function logHTTPTraffic(sub, data) {
sub.QueryInterface(Ci.nsIHttpChannel);
var ab = getTabFromChannel(sub);
console.log(tab);
}
observer.add("http-on-examine-response", logHTTPTraffic);
Mostly cribbed from the documentation for how to identify the browser that generated the request. Some is also taken from the Google PageSpeed Firefox addon.
Is there a recommended or preferred way to go from the nsIDOMWindow object domWin to a tab element in the SDK tabs module?
I've considered something hacky like scanning the tabs list for one with a URL that matches the URL for domWin, but then I have to worry about multiple tabs having the same URL.
You have to keep using the internal packages. From what I can tell, getTabForWindow() function in api-utils/lib/tabs/tab.js package does exactly what you want. Untested code:
var tabsLib = require("sdk/tabs/tab.js");
return tabsLib.getTabForWindow(domWin.top);
The API has changed since this was originally asked/answered...
It should now (as of 1.15) be:
return require("sdk/tabs/utils").getTabForWindow(domWin.top);
As of Addon SDK version 1.13 change:
var tabsLib = require("tabs/tab.js");
to
var tabsLib = require("sdk/tabs/helpers.js");
If anyone still cares about this:
Although the Addon SDK is being deprecated in support of the newer WebExtensions API, I want to point out that
var a_tab = require("sdk/tabs/utils").getTabForContentWindow(window)
returns a different 'tab' object than the one you would typically get by using
worker.tab in a PageMod.
For example, a_tab will not have the 'id' attribute, but would have linkedPanel property that's similar to the 'id' attribute.
When I tried to play around with Web Workers feature in HTML5, my firefox works happily but chrome complains that:
Uncaught TypeError: Cannot call method 'postMessage' of undefined
xstartWorkerworker.html:7 (anonymous function)worker.html:1
onclickworker.html:2
worker.html
<button onclick="xstartWorker()">Start worker</button>
<output id="result"></output>
<script>
function xstartWorker()
{
worker.postMessage({'cmd': 'startWorker', 'msg': 'Start now!'});
}
var worker = new Worker('worker.js');
worker.addEventListener('message', function(e)
{
document.getElementById('result').textContent = e.data;
}
, false);
</script>
worker.js
self.addEventListener('message', function(e)
{
var data = e.data;
switch (data.cmd)
{
case 'startWorker':
self.postMessage('worker thread start now:' + data.msg);
break;
default:
self.postMessage('default');
}
}
, false);
What I can do to make it works in chrome?
BTW, when I tried out the sample at http://playground.html5rocks.com/#inline_workers
and this time chrome works, but firefox complains that
Error: worker is undefined Source File:
http://playground.html5rocks.com/ Line: 39
I'm guessing you're trying to run this on your local machine, not on a webserver. Workers are restricted by the Same Origin Policy, but as the linked Wikipedia page notes,
The behavior of same-origin checks and related mechanisms is not
well-defined in a number of corner cases, such as for protocols that
do not have a clearly defined host name or port associated with their
URLs (file:, data:, etc.).
Loading a local file, even with a relative URL, is the same as loading a file with the file: protocol. So my guess is that the problem is that you're trying to load worker.js as a local file - Chrome doesn't like this (for some good security reasons), though you can force the issue by starting Chrome like this: chrome.exe --allow-file-access-from-files
Alternatively, try serving your script on a local or remote webserver and see if that fixes the problem. (If you have Python installed, you can go to the directory in question and run python -m SimpleHTTPServer 8000, then go to http://localhost:8000/ in your browser).
Chrome can use worker locally without the --allow-file-access-from-files. The worker needs to be loaded as a blob.
Example:
<body>
<button>Start</button>
<div id="output"></div>
<script id="worker_1" type="text/js-worker">
importScripts(base_url + '/worker_lib2.js');
function run(event) {
var msg = event.data;
this.postMessage({ answer: hello(event.data.name)});
}
this.addEventListener('message', run, false);
</script>
<script>
var base_url = window.location.href.replace(/\\/g,'/').replace(/\/[^\/]*$/, '');
var array = ['var base_url = "' + base_url + '";' + $('#worker_1').html()];
var blob = new Blob(array, {type: "text/javascript"});
$('button').click(function() {
var url = window.URL.createObjectURL(blob);
console.log(url);
var worker = new Worker(url);
worker.addEventListener('message', function(event) {
$('#output').html(event.data.answer);
}, false);
worker.postMessage({
name: 'Yannis'
});
});
</script>
</body>
The file worker_lib2.js :
function hello(msg) {
return 'Hello... ' + msg;
}