Closed Bug 1094257 Opened 5 years ago Closed 5 years ago

Worker failed to load script in new tab

Categories

(Core :: DOM: Workers, defect)

35 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: charles.jourdan, Assigned: baku)

References

()

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141105004006

Steps to reproduce:

I want to create a web worker using Blob. So I write :

var worker = new Worker(URL.createObjectURL(new Blob(["console.log('Hello world !!');"])));
worker.onerror = function(e){ console.error(e); };


Actual results:

An exception was thrown : Error: Failed to load script (nsresult = 0x805303f4).


Expected results:

This code should prints "Hello world !!" in the console.
(In reply to charles.jourdan from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101
> Firefox/35.0
> Build ID: 20141105004006
> 
> Steps to reproduce:
> 
> I want to create a web worker using Blob. So I write :
> 
> var worker = new Worker(URL.createObjectURL(new Blob(["console.log('Hello
> world !!');"])));
> worker.onerror = function(e){ console.error(e); };
> 
> 
> Actual results:
> 
> An exception was thrown : Error: Failed to load script (nsresult =
> 0x805303f4).

FWIW, this is NS_ERROR_DOM_BAD_URI . Do other browsers support blob uris for workers?

Also, I can't reproduce with a simple testcase (see URL field). It just works and gets  me the expected console log.
Component: Untriaged → DOM: Workers
Product: Firefox → Core
Huh, interestingly, clicking the link I just added breaks it (but with NS_ERROR_ILLEGAL_VALUE instead...). If I copy-paste the contents of the location bar and try again in a new tab, it works again. :-\

baku, am I right in thinking you know about our workers implementation? Any idea what's going on here?
Flags: needinfo?(amarchesini)
For me your URI works. In fact I have this issue when I open manually the tab (ctrl+t), open the developper tools (ctrl+shift+k) and finally enter the previous code.

I forget to specified I'm on Aurora channel. Sorry.
I test on firefox stable version and the issue doesn't appeared.

Also I see the url generated have not the same form. On Aurora the url looks like "blob:null/{hash}" and on stable version just "blob:{hash}".
I cannot reproduce the issue. Plus, I often write tests in such way.
Does it happen 100% of the times?

> Also I see the url generated have not the same form. On Aurora the url looks
> like "blob:null/{hash}" and on stable version just "blob:{hash}".

This because blob URIs use the origin of the page and probably you did your test in about:blank.
More info about this can be read in bug 1058470.
Flags: needinfo?(amarchesini) → needinfo?(gijskruitbosch+bugs)
(In reply to Andrea Marchesini (:baku) from comment #4)
> I cannot reproduce the issue. Plus, I often write tests in such way.
> Does it happen 100% of the times?

On current beta, on Windows, if I middle-click the link in the URL field, I get the following error:

Error: Failed to load script (nsresult = 0x80070057)

every time.

On Nightly, if I open about:home (default, initial tab), open the devtools console, and execute:

var worker = new Worker(URL.createObjectURL(new Blob(["console.log('Hello world !!');"])));
worker.onerror = function(e){ console.error(e); };

I get the same error.

If I then type 'about:blank' in the location bar, hit enter, and copy-paste the same code in the console, the code works fine. Typing about:home, enter, and trying again there yields the same error again.
Flags: needinfo?(gijskruitbosch+bugs)
Ok, now I'm able to reproduce the issue. The problem is that it's not possible to create a worker from about:home or any about: page.

The reason is that the Worker fails to retrieve the baseDomain from the principal of the document:

https://mxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4044

This happens because we try to use TLD service here:

https://mxr.mozilla.org/mozilla-central/source/caps/nsPrincipal.cpp#498

and in the end it fails here:

https://mxr.mozilla.org/mozilla-central/source/dom/base/ThirdPartyUtil.cpp#349
An 'easy' fix can be to support 'about' schema (and maybe others) in WorkerPrivate.cpp#4044.
But before doing it I want to have a feedback from bz.
Flags: needinfo?(bzbarsky)
We need the baseDomain bit because of our per-domain cap on number of workers, right?

If so, I think it would be reasonable to lump all the workers that we can't get base domain for into a single bucket for cap purposes.  But please double-check with bent.
Flags: needinfo?(bzbarsky)
bent, can you give a comment about this issue? Thanks!
Flags: needinfo?(bent.mozilla)
That sounds fine to me, maybe sicking has more of an opinion?
Flags: needinfo?(bent.mozilla) → needinfo?(jonas)
Seems fine to me. Are we already giving pages with chrome privileges unlimited number of workers? If not, we should.
Flags: needinfo?(jonas)
Assignee: nobody → amarchesini
(In reply to Jonas Sicking (:sicking) from comment #11)
> Seems fine to me. Are we already giving pages with chrome privileges
> unlimited number of workers? If not, we should.

This is a separated issue. about:home doesn't have chrome privileges.
Attached patch base.patch (obsolete) — Splinter Review
Attachment #8518881 - Flags: review?(bzbarsky)
Comment on attachment 8518881 [details] [diff] [review]
base.patch

Why would we ever have data: here?

Also, this doesn't seem like what I proposed in comment 8...  Can you explain why this is producing the behavior we want (and what that behavior is)?
Attachment #8518881 - Flags: review?(bzbarsky)
> Also, this doesn't seem like what I proposed in comment 8...  Can you
> explain why this is producing the behavior we want (and what that behavior
> is)?


Correct, it's not what you proposed. What this patch does is: when the page is about:something, or data:something (Actually I have to do more tests for data:), GetBaseDomain() returns error because we try to resolve the 'something' as a TLD (top-level domain). With this page, we don't do that when the schema is 'about:' or 'data:'. Instead we return 'something' as base domain.

This fixes the issue because, having a baseDomain makes possible the creation of the worker.
OK, but why do we want to make that specific to data: or about:?  Why not, for example, do it for all non-hierarchical URIs?

And do we really want to have the full worker limit per such URI?
Attached patch base.patchSplinter Review
Attachment #8518881 - Attachment is obsolete: true
Attachment #8519959 - Flags: review?(bzbarsky)
Comment on attachment 8519959 [details] [diff] [review]
base.patch

I think you want NS_URIChainHasFlags here.

r=me with that.
Attachment #8519959 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/0270b8b0fa4c
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
See Also: → 1104623
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.