Sources Page Tab retians previous Redirected Pages

[Edwin Simcock-Anthony]

Could someone please verify or provide guidance?

I'm using Response.Redirect from a VB server-side function, and while it behaves as expected (the new location is shown), I've noticed that the previous page remains in the Sources Page Tab. I expected it to no longer be present since the page should have been replaced after redirection.

Additionally, when I perform the redirection client-side (via <a href>), the redirecting page is removed from the Sources list and replaced with the new location as expected. Despite trying various modifications and different server-side redirection methods, I'm unable to remove the previous page from the list, and it persists until I end the session or close the developer tools.

For context, I've reproduced this issue using a simple two-page ASPX (server side response.redirect back and forth from button click) sample with no additional files and a basic web.config under .NET 4.8, demonstrating that there's no external influence involved.

Any ideas? Are these legacy files actually an issue?

[PhistucK]

Sounds a bit by design to me - this single user navigation got a server redirection (which will not appear in the history for the user to go back to), so all of the server redirections on the way to the final request get folded into the final page (I believe you see all of the redirections in the network panel, even if you do not choose to persist the log).

Does this cause issues, or is it just annoying/distracting to see them in sources?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chrome DevTools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/6c5c2ff5-96dc-466c-8272-4fd9ea7dda02n%40googlegroups.com.

[Edwin Simcock-Anthony]

Hello, and thank you.

To answer your question, it's a bit of both. I've been experiencing issues where the pages remaining in the sources tab don't always react as expected upon revisiting, and keeping them in the sources tab likely consumes overhead. Strangely, this issue wasn't always the case. Previously, the redirection would happen, and the new page would be the only one remaining. This still happens today, but now I have to do a full post back for it to work. Any kind of update panel usage or partial async, and the page remains. I can work around but feel that its not as clean left as it is.

[PhistucK]

> where the pages remaining in the sources tab don't always react as expected upon revisiting

This might indicate caching configuration issues, have you reviewed the caching-related response headers? 

☆PhistucK

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/5b834ef4-ab10-4506-b71e-40ecc9547dcan%40googlegroups.com.

[Edwin Simcock-Anthony]

Thank you. Yes, I have done that, but it’s a delicate balance between caching and performance. What I'm trying to determine is whether these 'stored' pages are causing additional issues beyond those I've observed. According to the documentation, Microsoft states that any response.redirect terminates the response once the page has been processed. This applies to all postbacks; however, any server button redirect or IsPostBack page load/redirect results in 302 statuses and gets stored in the sources tab. I would naturally assume that all server-side redirects, once managed, would no longer appear in the sources tab.