Even I get this behaviour randomly . Am not noticing this in other browsers. Sometimes  random scripts are being downloaded twice. 

i have attached screenshot for firefox Network panel.

Deleted: firefox1.png 830 KB

	firefox1.png 830 KB View Download

Can you please provide a file where this problem replicates?

@nivesoft : I tried executing your file. I did not get misbehaviour in normal window . But when I tried after switching to another person window, I got the issue while hard refresh( cmd + shift + R ) after 1 or 2 times. 

Can you also provide a network log when this happens so that we can see what's going on? This page describes how to provide network details: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.

I have attached network log file. check it.

Deleted: net-internals-log (2).json 384 KB

net-internals-log (2).json 384 KB View Download

Most of the files are downloaded twice. Please check my above attached logs.

Deleted: Screen Shot 2016-03-25 at 12.08.28 PM.png 1.4 MB

	Screen Shot 2016-03-25 at 12.08.28 PM.png 1.4 MB View Download

We have analysed little detail, in order to find whether execution occur multiple times ? We put console log in each file and executed the same in our local, but the result seems to be fine. Yes, execution happening only once. But when we check our access log and chrome network panel seems download happening multiple times. Please refer the attached screenshots.

Deleted: Screen Shot 2016-03-25 at 12.27.31 PM.png 1.4 MB

	Screen Shot 2016-03-25 at 12.27.31 PM.png 1.4 MB View Download

Deleted: Screen Shot 2016-03-25 at 12.27.58 PM.png 1.3 MB

	Screen Shot 2016-03-25 at 12.27.58 PM.png 1.3 MB View Download

Deleted: Screen Shot 2016-03-25 at 12.27.52 PM.png 1.0 MB

	Screen Shot 2016-03-25 at 12.27.52 PM.png 1.0 MB View Download

The resources are being requested with the BYPASS_CACHE load flag and the "Cache-Control: no-cache" request header.  Not something the network stack does itself, so these are combing from the renderer process somewhere.

Is this a Blink loader(renderer) bug?

I have tried this in multiple browsers, Trident ( IE ), Gecko ( Firefox ), WebKit ( Safari ) and Blink ( Chrome and Opera ), I can able to reproduce this only in Chrome and Opera. So, both use Blink engine.

Any update?

I can consistently reproduce this given the file provided in comment 4.

On first glance, it looks to me like we may be first requesting these files via the preload scanner, then re-requesting them when the parser actually needs them, rather than using the preload scanned versions. When the files are re-requested, I see them being requested in a stair-step in the waterfall that's consistent with the time that the parser requests them.

Adding pmeenan, japhet, and csharrison to get their take.

Where is the logic that tries to match parser requests with preload scanned responses? Do we have a sense for why it might not be matching these requests?

One subtle but perhaps important detail: the load flags for the parser requested version are load_flags = 258 (BYPASS_CACHE | VERIFY_EV_CERT) whereas the load flags from the preload scanned version, which is loaded first, are (BYPASS_CACHE | MAYBE_USER_GESTURE | VERIFY_EV_CERT). Perhaps we are encountering a miss because the load flags are different?

Thanks for looking into this. My guess is It's more likely due to the
double BYPASS_CACHE flags rather than MAYBE_USE_GESTURE on the second flag.

Is BYPASS_CACHE the correct flag here? These are just plain https script resources. Not clear why we'd be using bypass cache for those.

One more note: I would expect the second load of the resource, which seems to happen when the HTML parser encounters the script, to find the preloaded resource fetched during preload scanning, on the render process side, and not dispatch a second request down to net. So this seems like an issue on the render process side.

Pretty much all URL_REQUESTs have BYPASS_CACHE. Are you doing a shift-reload to trigger this? 

Yeah. mmenke noted the BYPASS_CACHE flag in his comment above as well. Perhaps the BYPASS_CACHE flag is not the real issue here.

For some reason the render-side logic to pair up preloaded requests doesn't seem to be doing so, as best I can tell.

Assigning to Nate just to get a sanity check on this, since I don't understand this code well.

Nate, which code in blink matches up preloads requested from the html preload scanner with the later use of that resource when e.g. the parser actually encounters a blocking script and needs to load it?

Do you have a sense as to whether/why we might be failing to match requests up in some cases, and allow the requests to fall through to the net stack?

Nate, please feel free to unassign once you've taken a look and left comments.

Thanks!

Yes, agreed.

By removing the "language" attribute on the scripts I've stopped the double downloading. I know exactly where that check is in the code though.

Sorry, that should say I *don't* know exactly where that check is in the code. I'm taking a look though.

I tested the script on TOT (#385459) and could not reproduce.

Is this Issue fixed in Version 50.0.2661.75 (64-bit)? Its working properly, Script is downloaded once. Thx.

Marking as fixed for now, given this doesn't repro anymore. Please re-open if you are able to repro on Chrome 51+.