Bug 36399 – WorkerScriptLoader always (and unfortunately sometimes) inherits caching policy from the parent context.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore JavaScript

[Dmitry Titov]

Probably since we switched from using CachedScript to ThreadableLoader in WorkerScriptLoader (http://trac.webkit.org/changeset/44726), the caching behavior changed in somewhat unfortunate way: when the page that creates more then 1 worker from the same script is "reloaded", it re-validates all the resources via server roundtrip and if multiple workers are created from the same url, they get revalidated every time.

Here is the test created by Drew Wilson: http://www.corp.google.com/~atwilson/worker-latency.html

Click the link, it'll create several workers. Note the printed time. Hit refresh. It'll create several workers again, this time taking longer for each one, for roundtrip to the server.

[Darin Fisher (:fishd, Google)]

See http://code.google.com/p/chromium/issues/detail?id=34092#c10.  I don't think this bug is unique to workers, and the fix probably can be made to SubresourceLoader in a manner that would work for all resource loads made after the page has loaded.

[Alexey Proskuryakov]

See also: bug 32423, bug 30862. We seem to be having two opposite bugs at once.

[Andrew Wilson]

Created attachment 51470 [details]
HTML file that shows this bug

[Andrew Wilson]

Created attachment 51471 [details]
Associated JS file (worker script) that shows the bug.

Added worker-latency.html and worker.js files as attachments for this bug. Download both files into a single directory, load worker-latency.html in a browser, then hit reload to reproduce the issue.

[Tony Gentilcore]

This no longer reproduces using atwilson's test case. Worker loaded scripts come from the cache even after a reload. Please reopen with explanation if I'm missing something.

[David Levin]

Likely it works now due to Nate's changes here http://trac.webkit.org/changeset/98380 and subsequent related changes later.