This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28737 - Request to extend importScripts(urls) for ServiceWorkerGlobalScope
Summary: Request to extend importScripts(urls) for ServiceWorkerGlobalScope
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-02 06:38 UTC by Jungkee Song
Modified: 2015-09-02 19:02 UTC (History)
4 users (show)

See Also:


Attachments

Description Jungkee Song 2015-06-02 06:38:14 UTC
Currently service worker monkey patches the importScript(urls) method for its own environment: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#importscripts

Incorporating this requirement in HTML would be more accurate. Could you address this?

Here's the related discussion: https://github.com/slightlyoff/ServiceWorker/issues/106#issuecomment-51204543
Comment 1 Anne 2015-08-28 11:37:06 UTC
Would it not be easier for service workers to define its own method? Domenic's preference is that if they have a distinct implementation they should just be their own methods.
Comment 2 Domenic Denicola 2015-08-28 12:49:05 UTC
This is kind of tricky though because either the SW importScripts will need to be defined as "like HTML's importScripts, but insert these steps at these positions" or SW will need to copy all the steps from HTML. The former seems fragile to any bugfixes in importScripts, and the latter will get out of date.

What do you think of extracting HTML's importScripts definition into a "import scripts in to worker scope" algorithm, which has hooks that can be overridden? The hooks I see needed are:

- A validation step, after step 1. In HTML this does nothing.
- A generic fetching step, replacing step 5. In HTML this does what step 5 currently does.
- A postprocessing step, between steps 6.1 and 6.2. In HTML this does nothing.
Comment 3 Jungkee Song 2015-08-31 09:22:35 UTC
I think incorporating the changes directly in HTML would be even better. Is there a reason that's not preferable? If so, I can do what Domenic suggested.

FYI. I'd want to make another PR for appcache too: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27482.
Comment 4 Anne 2015-08-31 09:43:30 UTC
What Domenic suggests seems good. To be clear, PRs need to be against https://github.com/whatwg/html. Thank you!