Operaritve: No operative.js URL available. Please set via operative.setSelfURL(...)
rileyjshaw opened this issue · comments
Hey there,
I'm trying to set operative's SelfURL to the version hosted on cdnjs, but I can't get it to work. The following:
var operative = require('operative');
operative.setSelfURL('https://cdnjs.cloudflare.com/ajax/libs/operative/0.4.1/operative.js');
var worker = operative(function (cb) { /* ... */ });
worker(function () {/* ... */});
};throws an error in IE10:
Operaritve: No operative.js URL available. Please set via operative.setSelfURL(...)
I've tried a few configurations:
// 1
operative.setSelfURL('https://cdnjs.cloudflare.com/ajax/libs/operative/0.4.1/operative.js');
// 2
operative.setBaseURL('https://cdnjs.cloudflare.com/ajax/libs/operative/0.4.1/');
// 3
operative.setBaseURL('https://cdnjs.cloudflare.com/ajax/libs/operative/0.4.1/');
operative.setSelfURL('operative.js');...but nothing has worked. Any thoughts?
This is completely my bad. Got a PR open (#37). I'll make sure it works properly and is merged in the morning when I'm more awake.
Thanks for reporting!
Awesome - thanks!!
Self-URL setting was indeed broken and am en-route to releasing that fix, but I don't think this'll help you. Operative's general fallback for IE10 (since it doesn't support the creation of workers via blobs) is to create a new worker that points to the operative script itself. I.e.
new Worker('the/path/to/operative.js');For these purposes, the operative script must be of the same origin as the parent page. So, a cdnjs-hosted script will not work.
What I suggest is using the cdnjs script, as you are, but having a locally hosted operative.js script which you point to in setSelfURL(). This'll only be used where worker-via-blob support is lacking (AFAIK this is only IE10).
That fix will be in soon anyhow.
Hmm - alright, that's good to know. I figured there would be same-origin requirements, but I was crossing my fingers that I was wrong.
I was hoping to use cdnjs to simplify bundling my app - allow people to simply require('myLib') instead of require-and-also-include-this-static-file-beside-your-bundle. But it sounds like if I want to support IE10, I'll have to go the second route...
Thanks so much for responding to these issues! I'm writing a little library for programming quizzes and using operative as a sandbox... I'm probably pushing to Github sometime this week, I'll let you know when it's up.
Your project sounds cool! It's a real shame about IE10. I guess one other option for you would be to detect IE10 yourself and then force operative to fallback to an iframe context by fooling it into thinking workers aren't supported at all: (Of course, this means you can't benefit from the non-blocking/sandboxed nature of workers in IE10...)
if (/*IE10 check*/) {
operative.hasWorkerSupport = false;
}
// Do regular operative stuff now(0.4.3 is now released btw)
@padolsey thanks for looking into this. I'm playing around with the new version, and can't seem to trigger my callback in IE10 workers... were you able to get this working?
I'll probably just go with your /*IE10 check*/ solution. Any recommended ways of doing this? (I'd rather do feature detection like operative has done rather than user agent sniffing)
Does this work for you? - http://james.padolsey.com/demo/operative_ie10/ (I've only been able to test it with BrowserStack so far, so that may be misreporting the reality of it)
(That page should alert() a message if it's working)
For the IE10 check, you could try:
operative.hasWorkerSupport = operative.hasWorkerViaBlobSupport;This will make operative only use workers when it can do so via blobs.
@padolsey it works!! 👯
Turns out my path variables were off. With the final piece of IE10 in place, I think I'm about ready to ship!
Cool! Love the configurability!