Closed Bug 1090183 Opened 5 years ago Closed 5 years ago

NS_ERROR_FAILURE in WebSocket in SharedWorker

Categories

(Core :: DOM: Workers, defect)

36 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox35 ? ---
firefox36 - ---

People

(Reporter: aneesiqbalbhatti, Assigned: baku)

References

Details

Attachments

(2 files)

Attached image Capture.PNG
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141027030204

Steps to reproduce:

Downloaded Firefox Nightly
Created a web app that uses Shared WebWorker
Tried to create a WebSocket from within the Shared WebWorker


Actual results:

It threw NS_ERROR_FAILURE exception


Expected results:

It should've established a connection the same way it does when trying to create a websocket to the same address from outside the worker.
Component: Untriaged → DOM: Workers
Product: Firefox → Core
[Tracking Requested - why for this release]:
Bug 504553 landed for v35, and this kind of errors might require us to disable WebSocket-in-Workers in aurora.
Summary: NS_ERROR_FAILURE in WebWorker WebSocket → NS_ERROR_FAILURE in WebWorker WebSocket in Shared Worker
Summary: NS_ERROR_FAILURE in WebWorker WebSocket in Shared Worker → NS_ERROR_FAILURE in WebWorker WebSocket in SharedWorker
So we land in InitRunnable::MainThreadRun and it does:

862         // Walk up to our containing page
863         WorkerPrivate* wp = mWorkerPrivate;
864         while (wp->GetParent()) {
865           wp = wp->GetParent();
866         }
867     
868         nsPIDOMWindow* window = wp->GetWindow();
869         if (!window) {
870           mRv.Throw(NS_ERROR_FAILURE);

Looks like we get the principal from the window's current document, and use the window to init an AutoJSAPI.

Andrea, could we just init the AutoJSAPI to some main-thread-side global with the right principal (hey, the sandbox thing again!) and get the principal from the workerprivate?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(amarchesini)
OS: Windows 8.1 → All
Hardware: x86_64 → All
Summary: NS_ERROR_FAILURE in WebWorker WebSocket in SharedWorker → NS_ERROR_FAILURE in WebSocket in SharedWorker
> Andrea, could we just init the AutoJSAPI to some main-thread-side global
> with the right principal (hey, the sandbox thing again!) and get the
> principal from the workerprivate?

Correct, this is what I'm planning to do. I'm wondering if we can have 1 single sandbox for sharedworker. at the moment we have needs for console and webSocket.
Flags: needinfo?(amarchesini)
Attached patch sw.patchSplinter Review
Actually, we don't need the sandbox for this issue because the only use if the JSContext is to retrieve the inner Window ID.

For SharedWorkers/ServiceWorkers and DedicatedWorkers from JSM we are windowless.
Attachment #8513372 - Flags: review?(bugs)
Comment on attachment 8513372 [details] [diff] [review]
sw.patch

Please add a test which checks the websocket connection actually does something in sharedworkers.
With that, r+
Attachment #8513372 - Flags: review?(bugs) → review+
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c898d0750636

tested added and pushed to try. If fully green I'll land the patch.
> I'm wondering if we can have 1 single sandbox for sharedworker.

I think we should, yes.
https://hg.mozilla.org/mozilla-central/rev/04ecddfdb50b
Assignee: nobody → amarchesini
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.