Created attachment 114046 [details] testcase Open attachment or URL Opera 11.5 - pass
Firefox added it in nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=699857
Why are you saying that this should work? HTML5 is very specific that it's not allowed. It's curious that Mozilla folks decided to diverge from the spec, especially without ever mentioning a rationale. The only discussion of this proposal on standards list that I could find ended with the idea being rejected. ----------------------------- When the Worker(scriptURL) constructor is invoked, the user agent must run the following steps: 1. Resolve the scriptURL argument relative to the entry script's base URL, when the method is invoked. 2. If this fails, throw a SyntaxError exception. 3. If the origin of the resulting absolute URL is not the same as the origin of the entry script, then throw a SecurityError exception. Thus, scripts must be external files with the same scheme as the original page: you can't load a script from a data: URL or javascript: URL, and an https: page couldn't start workers using scripts with http: URLs.
If you use main stript as https, dataURI is https to, because it is from the same source. If you use main stript as http - dataURI is http to, because it is from the same source. Generaly, dataURI has the same origin like main stript.
You can use: blob = new BlobBuilder() & URL.createObjectURL(blob) but dataURI is simpler and faster to write.
This is just another instance of a long-standing difference between Firefox and WebKit. WebKit treats data URLs as having a unique origin whereas Firefox treats them as inheriting the origin of their creator. This bug will get fixed if (and when) we converge with Firefox in this behavior. I don't think we should fix this as a one-of for workers.
I am unable to reproduce this bug in Safari 15.6 on macOS 12.5 and it shows "Pass" upon clicking "test worker" and it is same across all other browsers as well (Chrome Canary 106 and Firefox Nightly 105). Assuming that the test case is right (didn't see any console warning) and now behavior is consistent across all browsers, I think we can mark this as "RESOLVED CONFIGURATION CHANGED". Thanks!
Agreed.