Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle any.js or variants in a window global scope which is controlled by a service worker #11962

Open
makotoshimazu opened this issue Jul 13, 2018 · 8 comments

Comments

@makotoshimazu
Copy link
Contributor

We run *.any.js on window, dedicatedworker, serviceworker, sharedworker scopes, but we don't have a way to specify those global scopes hosted by a service worker.
It changes the behavior of network requests, so it will exercise more codes.

For example, wpt/fetch/api are written by *.any.js but all network requests in those tests won't be routed to service workers.

@foolip
Copy link
Member

foolip commented Jul 18, 2018

Hmm, interesting. Could the same service worker be used for all such tests, just to see that it is "transparent"?

@annevk, do you think this would be technically straightforward to implement?

@makotoshimazu
Copy link
Contributor Author

I think service workers should be transparent to those tests, but service workers themselves may be needed to be modified in some ways independently with tests (like caching, fetching explicitly from the network in the service worker, and just returning with nothing else).

@foolip
Copy link
Member

foolip commented Jul 19, 2018

Right, so the point of this is to discover bugs in the service worker implementation, cases where the behavior has changed even though the service worker isn't set up to do anything?

Are any tests like this written manually right now?

@annevk
Copy link
Member

annevk commented Jul 23, 2018

How does this make sense for the serviceworker "scope" of an any.js test? Adding more "scopes" is somewhat straightforward, but it would be good to make the proposal a bit more concrete.

@foolip
Copy link
Member

foolip commented Jul 24, 2018

@makotoshimazu can you point to some tests that do this kind of thing manually, presumably duplicating some code, to illustrate the problem?

@makotoshimazu
Copy link
Contributor Author

Thanks for digging into this!

Scope seems depending on the performance of the test. Tests should work regardless of its scopes if we only registers "transparent" service workers which I mentioned in the bottom. More registrations would improve concurrency of test execution.

As an exmample of manual registration, fetch-event.https.html is a test that adds a scope and loads a resource, but I don't think this test is a representative of that kind of thing since it's only for pages controlled by a service worker (of course some of tests whose service worker falls back to the network should work even when service worker doesn't control the page, though).
And during looking for a good example to put here, I realized that unfortunately we don't have a good coverage of tests for pages controlled by a service worker unfortunately...

I think those four cases are popular and should be transparent to tests. All any.js tests probably should pass with those service workers.

  • run any.js on a page which is controlled by a service worker without a fetch event handler (blank js is okay for the service worker).
  • run any.js on a page which is controlled by a service worker with a fetch event handler but empty function. ex: self.onfetch = () => {}
  • run any.js on a page which is controlled by a service worker with a fetch event handler but calls fetch(). ex: self.onfetch = e => { e.respondWith(fetch(e.request)); }
  • run any.js on a page which is controlled by a service worker with a fetch event handler, which returns a response from cache storage.

@annevk
Copy link
Member

annevk commented Jan 14, 2020

Sorry for not following up here. It seems like a reasonable suggestion to increase test coverage for service workers, but should probably be opt-in per test to avoid clashes?

@annevk
Copy link
Member

annevk commented Jan 14, 2020

Note also #21163 by the way. Currently many tests could be run in a service worker, but don't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants