Could you please provide a sample application to reproduce the issue from test team end. A screencast would be helpful

I have attached 6 screenshots where gaTracking.js is referenced at line number 2601 in homepage when i clicked on the initiator link it will landed to homepage line number 2601 in resources tab where it is referenced (refer scr2.png).
When I visit prescription page  the gaTracking.js is still showing line number 2601(refer scr3.png) in prescription page and when I clicked on the prescription page this page is not having line number 2601 (refer scr4.png).
When I reloaded the page shift+F5 it is showing the correct line number 1025 (refer scr5.png and scr6.png)

The application is not live so i can't provide the URLS if i found same behaviour in a live application than i will share the URLS.
Please let me know if  further information is required from my side .  

Deleted: scr1.PNG 55.7 KB

	scr1.PNG 55.7 KB View Download

Deleted: scr2.PNG 47.3 KB

	scr2.PNG 47.3 KB View Download

Deleted: scr3.PNG 48.5 KB

	scr3.PNG 48.5 KB View Download

Deleted: scr4.PNG 23.1 KB

	scr4.PNG 23.1 KB View Download

Deleted: scr5.PNG 31.5 KB

	scr5.PNG 31.5 KB View Download

Deleted: scr6.PNG 42.5 KB

	scr6.PNG 42.5 KB View Download

Thank you for providing more feedback. Adding "Needs-Review" label for tracking.

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

Hmmm interesting, I think this may be caused from a combination of reasons that line up for you.

1) Can you please ensure it still exists on stable?
2) Check to see if it exists on Canary?
3) On stable try disabling cache and see if it exists?

Thanks!

I further analysed below are the findings.

Able to replicate the issue only on the development environments not having valid SSL certificates(non disable cache) not able to replicate on the environment having the valid SSL certificate, Is this something related to SSL certificate?

Thanks 

Reload behavior is/was going through a change in the way it works when on the same domain. I am not sure if SSL follows the same flow path (probably not).

Do you have a sample demo for us to investigate this issue?

Can you check to see if it exists on Canary?

I am able to replicate same issue on Canary also.
And I found more details on canary while analysing on both the environments with and without valid SSL.
As per my analysis chrom maintains two king of cache memory and disk caches.
and issue only exists for the resources stored on memory cache if any resource is stored in disk it is  showing the correct line number.
not sure why it is  storing resources from same domain in memory if not on valid SSL and storing on disk if on valid SSL.

Hoe this helps!

Correct. I was betting on disk vs memory cache being the issue as well.

+toyoshim, do you see why this might be happening on the top of your head?

It could be possible if initiator information were stored in memory cache, but actually I don't know details how initiator information are reported to the DevTools.

allada@, what kind of interface should be called to report such information? If it was called from memory cache or related code, we'd try to fix this.

CCed to hiroshige who are working on memory cache.

I have another bug dealing with redirects and initiator info. I have identified the bug to be because "willSendRequest" is being sent twice to devtools causing the GUI to act strange. I think we may be dealing with a similar situation. Let me investigate this possibility further before anyone spends any more time on it.

We need to investigate. Stray guess is preload scanner is caching something.