There was a mistype in the report:

Put a function on the "onerror" to **remove** the script from DOM does not prevent the duplicated request. 

Also, file has to be served through http:// or https:// to reproduce the problem.

Unable to reproduce the issue on windows 7, Mac 10.12.4 using chrome version 58.0.3029.81 with the below steps

1.Opened the attached html file on chrome
2.Open dev tool console
3.Observed only 10 errors logged.
4.Refresh the page
5.Still observed 10 errors in console and network tab also

Please find the attached screen cast and confirm if anything missed here.
Request you once try the issue by upgrading chrome to latest stable and update the thread if the issue still persists.

Thanks,

Deleted: 717507.mp4 960 KB

	717507.mp4 960 KB View Download

I have already made it clear in comment#2 that you have to load this page through `http://` or `https://`. `file://` does not reproduce this issue.

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

And here is a screencast.

Deleted: screencast.m4v 5.0 MB

screencast.m4v 5.0 MB Download

Re-upload as .mp4 so it can be viewed directly.

Deleted: screencast.mp4 5.0 MB

	screencast.mp4 5.0 MB View Download

Confirmed on 60.0.3094.0 canary on Windows 7. Investigating...

Also confirmed on Linux, quite flakily though (once per ~20 reloads).
This also occur when DevTools is not opened.

This looks like preloading doesn't work with non-image 4xx/5xx responses.

On ToT:
- ResourceLoader::DidReceiveResponse() cancels the loading explicitly when
  the HTTP status >= 400 and Resource::ShouldIgnoreHTTPStatusCodeErrors()
  returns false.
  (This is the case for all resources except for ImageResource and
   RawResource)
- Canceling the loading causes evicting the response from preloads_
  in ResourceFetcher::HandleLoaderError().

Therefore, in the following case:
1. the 404 response for the preloading request is received, and then
2. <script> tag is processed and the main request is started,
the preloaded resource is evicted from preloads_ in Step 1 and a new network
request is started in Step 2.

I haven't investigated how the things work before yhirano@'s recent changes on
preloading and MemoryCache.

Assigning to yhirano@ who is changing the preloading mechanism.

My change didn't change the behavior. Before my change, preloaded resources were stored MemoryCache, and cancelled resources have been removed from the memory cache in Resource::FinishAsError.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is a sort of duplicate of  issue 634221 . As we closed that issue as WONTFIX, we should have the same conclusion.