1245906 - Scope is not honored by ServiceWorker

Status: RESOLVED INVALID

(Core :: DOM: Service Workers, defect)

Description

[william.jblankenship]

User Agent: Mozilla/5.0 (Android 6.0.1; Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Build ID: 20160120160101

Steps to reproduce:

Register a service worker under `./`, on a URL, say `127.0.0.1:8000/`. Trigger a request outside of that scope, say `wss://tracker.webtorrent.io`.

An example of this happening can be found at retrohacker.github.io/peerweb seed content and then attempt to download it. My ServiceWorker will complain that the request isn't in scope and the wss will fail.


Unrelated question: there doesn't seem to be a way for a ServiceWorker to pass through a request unmodified and `self.fetch` appears to break `wss` connections (possible that my service worker isnt configured right). Is the only way to pass a request through a ServiceWorker to call `self.fetch`? Or can you just `return null` and let the request finish that way?


Actual results:

The service worker intercepts the request. You can verify by doing a `console.log` on every request coming in.


Expected results:

The request shouldn't have been seen by the ServiceWorker.

Comment 1

[william.jblankenship]

* The user agent I used when filing this bug is not the one I'm experiencing the problem on

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Is this a dupe of the websocket bug you just landed?

Comment 3

[(no longer active)]

Yes, this is bug 1243942.  We're going to fix it in Firefox 44.0.1.  Sorry about this...

(In reply to william.jblankenship from comment #0)
> Unrelated question: there doesn't seem to be a way for a ServiceWorker to
> pass through a request unmodified and `self.fetch` appears to break `wss`
> connections (possible that my service worker isnt configured right). Is the
> only way to pass a request through a ServiceWorker to call `self.fetch`? Or
> can you just `return null` and let the request finish that way?

The websocket handshake connection should not be intercepted by the service worker in the first place.  The bug in Firefox caused us to mistakenly invoke the service worker, breaking WebSocket usage.

Comment 4

[william.jblankenship]

That was an aside.

The problem is that the service worker is intercepting requests that are outside of it's scope.

Comment 5

[william.jblankenship]

(It is possible that I misunderstand how firefox treats scope. Does scope refer to the origin or destination of the request?)

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

(In reply to william.jblankenship from comment #4)
> The problem is that the service worker is intercepting requests that are
> outside of it's scope.

The scope is used to determine if a document should be controlled by the service worker.  Once the document is controlled all requests (within scope or not) will be intercepted by the controlling service worker.

Are you saying the document using websockets was not within scope of the service worker or was not controlled?

Comment 7

[william.jblankenship]

Ah. Yes. I misunderstood scope.

I didn't understand that all requests were intercepted from any document within scope. I was under the impression scope limited the requests a service worker could see from a document.

Thanks for clearing that up!