Closed
Bug 1090183
Opened 10 years ago
Closed 10 years ago
NS_ERROR_FAILURE in WebSocket in SharedWorker
Categories
(Core :: DOM: Workers, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: aneesiqbalbhatti, Assigned: baku)
References
Details
Attachments
(2 files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•10 years ago
|
Component: Untriaged → DOM: Workers
Product: Firefox → Core
Comment 1•10 years ago
|
||
[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.
tracking-firefox35:
--- → ?
tracking-firefox36:
--- → ?
Updated•10 years ago
|
Summary: NS_ERROR_FAILURE in WebWorker WebSocket → NS_ERROR_FAILURE in WebWorker WebSocket in Shared Worker
Updated•10 years ago
|
Summary: NS_ERROR_FAILURE in WebWorker WebSocket in Shared Worker → NS_ERROR_FAILURE in WebWorker WebSocket in SharedWorker
Comment 2•10 years ago
|
||
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)
Reporter | ||
Updated•10 years ago
|
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
Assignee | ||
Comment 3•10 years ago
|
||
> 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)
Assignee | ||
Comment 4•10 years ago
|
||
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 5•10 years ago
|
||
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+
Assignee | ||
Comment 6•10 years ago
|
||
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c898d0750636
tested added and pushed to try. If fully green I'll land the patch.
Assignee | ||
Comment 7•10 years ago
|
||
Comment 8•10 years ago
|
||
> I'm wondering if we can have 1 single sandbox for sharedworker.
I think we should, yes.
Comment 9•10 years ago
|
||
Assignee: nobody → amarchesini
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•