18 April 2013

Cross origin web worker in an iframe

To the point: One can use embedded web workers but only Chrome and Firefox support that kind of setup at the moment through the use of blobs. I tried it on IE and it logs some 'security error'. For other browsers I didn't try to find what was the reason.
I think this may be to prevent cross origin workers. But we can already add scripts dynamically like in JSONP or do a CORS then eval...
So why is a cross origin executed code worse if it is a worker? I imagined it would be better because of the limited root context...
And it looks an even less good reason when you can use simple iframe communication to overcome that no-file-no-worker policy, like I did in an example a bit below.

On another hand if this is about file length or organization - a long time executing does not mean a long code or is it synonym of belonging elsewhere...

My temporary conclusion is no one wants to be associated with the introduction of yet another way to execute cross origin javascript.
Some web pages already tend to throw every possibly unwanted thing at your face. This will not make that or the solution to that any different. But will add the value of the time spent in segmenting long executions or creating an external iframed worker (in the cases where people are bound to have one file, like me here).


Anyway, an iframe web worker example:




Type anything to eval asynchronously in the iframe web worker context:
A clock:

Worker posts:

iframe or worker error:


Base sources:

Mozilla
https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers
https://developer.mozilla.org/en-US/docs/DOM/window.postMessage
https://developer.mozilla.org/en-US/docs/HTML/Element/iframe

Stackoverflow
http://stackoverflow.com/questions/5408406/web-workers-without-a-separate-javascript-file
http://stackoverflow.com/questions/11354992/why-the-web-worker-cant-call-a-function

No comments:

Post a Comment