User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce: 1. Clone https://github.com/guybedford/modules-link-preload 2. Run a local server 3. Open test-shallow.html Actual results: There is a deep module tree being loaded here with the last module being preloaded. A normal script will be preloaded fine in version 56, while a module script doesn't appear to be using the preload cache. Expected results: Module scripts should be compatible with link preloads, to assist with deep dependency tree hinting for faster loads.

So test.js and module999.js are prefetched. script type="module" is not implemented in firefow it does not get executed.

I should clarify that this is with the dom.moduleScripts.enabled;true flag set.

Thanks. For some reason we decide to drop cache entry before it is written into.

Michal, can you take a look why we are dropping cache entry before it is written into it? I am interested in caching for module999.js which is preloaded (link rel=preload). Is there a way to force caching, so that cache entry is not dropped? (at the same time a resource must be cacheable, I do not want to change validity of a cached resource)

The cache has been cleared (according to the timestamp at Jul 11 15:55:35 UTC 2017) and the eviction context is still on the disk. When opening the file it is checked whether it was evicted or not: 2017-07-11 15:55:54.508578 UTC - [Cache2 I/O]: D/cache2 CacheFileContextEvictor::WasEvicted() [key=:http://127.0.0.1/lib/module999.js] 2017-07-11 15:55:54.508598 UTC - [Cache2 I/O]: D/cache2 CacheFileContextEvictor::WasEvicted() - evicted [pinning=0, mTimeStamp=1499788535000, lastModifiedTime=1499787425000 the file is older but dooming is deferred until pinning status is known. Later, instead of dooming, we truncate the file and use it as a new file: 2017-07-11 15:55:54.623812 UTC - [Cache2 I/O]: D/cache2 CacheFileMetadata::ParseMetadata() - handle was doomed for this pinning state, truncate the file [this=0x7fe1fc0036a0, pinned=0] 2017-07-11 15:55:54.623824 UTC - [Cache2 I/O]: D/cache2 CacheFileIOManager::TruncateSeekSetEOF() [handle=0x7fe1fc0035b0, truncatePos=0, EOFPos=0, listener=(nil)] This all seems to be correct and I see that some content is then written to the file and the handle is not doomed when it is closed. How did you find out that the entry is dropped? Btw, the same happens in the log again for the same URL, but it is loaded as anonymous, so it is a different entry.

When testing with a fresh cache, I can see the module999.js file being requested twice in the network panel, as well is in the logs from my local server. What do you mean by "the same happens in the log again for the same URL, but it is loaded as anonymous, so it is a different entry". The issue here is that module999.js is preloaded as a script module, and then loaded again, which should be enough for the preload scenario to work, and as expected from the specification.

preloaded module999.js and the second load of the same file have different flags, i.g. one is annonimous and the other not. I need to figure out why this is happening...

Ah, I only just found out about this issue - https://github.com/whatwg/fetch/issues/486. In my previous discussion with the spec authors I was led to believe that as="module" would be enough. Hopefully we can get some spec clarity here, as this is critical for production performance of modules.

Is this a dupe of bug 1342416?

Yes it looks like it is, thanks.