Closed Bug 1090183 Opened 10 years ago Closed 10 years ago

NS_ERROR_FAILURE in WebSocket in SharedWorker

Categories

(Core :: DOM: Workers, defect)

36 Branch
defect
Not set
normal

Tracking

()

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

People

(Reporter: aneesiqbalbhatti, Assigned: baku)

References

Details

Attachments

(2 files)

Attached image Capture.PNG (deleted) —
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.patch (deleted) — Splinter 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.
Assignee: nobody → amarchesini
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: