New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 141129 link

Starred by 173 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

DevTools: XHR (and other resources) content not available after navigation.

Project Member Reported by vsevik@chromium.org, Aug 7 2012

Issue description

1) Turn on Developer tool, surf to Network tab, select "XHR" and enable "Preserve Log upon Navigation.
2) http://store.apple.com/hk/engrave/MC297ZP/A?not-engraved=not-engraved
3) Select "Check Out Now" button

Content for hybrid_cartx is not available because NetworkResourcesData collects it upon navigation.

Originally reported in:
http://code.google.com/p/chromium/issues/detail?id=116990
http://code.google.com/p/chromium/issues/detail?id=118971
 
As a workaround you can do something like 

  window.onunload = function() {debugger;}

from console.

Comment 2 by vsevik@chromium.org, Aug 16 2012

Issue 139226 has been merged into this issue.

Comment 3 by vsevik@chromium.org, Oct 11 2012

 Issue 134395  has been merged into this issue.
Had a hard time until realized that it is Chrome who is not showing the results. I thought the problem was on server side, but it appeared in client. Didn't expect Chrome tool to fail.

What is the updated status of "Assigned"? Is there an upstream bug or some serious problems with fixing this?
Project Member

Comment 5 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Feature-DevTools Cr-Platform-DevTools Cr-Content
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Comment 7 by kelvin...@gmail.com, May 28 2013

any update about this issue? opened for almost 1 year!!!

Comment 8 by eustas@chromium.org, May 28 2013

Owner: eustas@chromium.org
 What I see is that resources that hasn't been viewed in network panel will be inaccessible after page navigation.

 This is an outcome of "low overhead" policy - resource content isn't transferred to DevTools until user explicitly want's to view it. This is done to avoid skewing measuring results.

 Of course, we could keep resources even after navigation, but this will add memory burden: imagine, user (or site itself) continuously and indefinitely navigates...

 Current solution is a good compromise: user can examine resources between navigations, if he likes; on the other side - user can examine network timing of multiple navigations on a single timeline.

 We would be glad to add more flexibility, but we need real use-cases to make sure that this will be useful.

Comment 9 by qubith...@gmail.com, Jun 28 2013

There are many cases where a re-direct occurs very quickly; prior to being able to inspect the response.  In these cases, an alternative tool has to be used in order to inspect the contents of the response that caused the re-direct.  It would be extremely helpful if there was some way to inspect the contents with devtools.

Comment 10 by fre...@gmail.com, Jun 29 2013

An ability to set http://www.charlesproxy.com/ style breakpoints for the HTTP requests would be fantastic here.
 Issue 284941  has been merged into this issue.
is there any plan when this issue will be fixed? thanks
There was a take one: https://codereview.chromium.org/22548007

Vsevolod says that fetching resources to frontend is an overkill.
Pavel Feldman says that we shouldn't preserve resources on backend.

So, there is no way to fix this, until you find a way to convince one of them.

Comment 14 by fredsa@google.com, Sep 10 2013

Could we perhaps change the behavior of either frontend or backend when developer tools are open, i.e. when the developer is explicitly debugging?
Both backend and frontend work only when devtools are open. That's not enough.
The worries about overkill could be alleviated with the (efficiently implemented) ability to allow some type of declarative selector setting that would match the response and trigger the preservation; rather than the current selector mechanism which is a user clicking around in the UI.  Along the lines of what fredsa mentioned above, but not a breakpoint, just a triggering mechanism to preserve the content.
 Issue 292957  has been merged into this issue.
 Issue 292954  has been merged into this issue.
 Issue 309140  has been merged into this issue.
many issue were merged to this one, but still not yet fixed in 20 months. why?
 Issue 256917  has been merged into this issue.
Issue 373754 has been merged into this issue.
if of any interest, the data that does not show in DevTools shows in net-internals, see screenshot from Issue 373754.
 Issue 445680  has been merged into this issue.

Comment 25 by dexb...@gmail.com, Dec 31 2014

I just want to say: Programmer Help Programmer !

This is very convenience feature for developers.
Right you are. But there is a deadlock:
https://code.google.com/p/chromium/issues/detail?id=141129#c13

Comment 27 by dexb...@gmail.com, Dec 31 2014

Yes, I saw that, so I can only say that. However, unload event debugger works fortunately. 
And thank you for your help.
 Issue 453078  has been merged into this issue.
"Current solution is a good compromise", no it isn't. It's a totally shitty compromise.

The solution is pretty obvious.
Just put a checkbox to let the developer choose whether to preserve data after navigation, just like the "preserve log" option. I can't believe this hasn't been done in more than two years. 


 Issue 460777  has been merged into this issue.
Hm... "preserve data after navigation" seems like a possibility, but sounds an awful lot like "preserve log" - I doubt that'll help avoid much confusion, though it'd be useful for those who understand the problem as a workaround.  Maybe a better option would be "break on navigation" where you could inspect anything you want to before resuming?  Or if navigation is triggered by an xhr success / completion / error callback, just always saving that one response?
btw the least Chrome could do here is to display a more informative error message.  It's stupid for people to think the "failed to load response" means a server error.  Maybe "response data not available because navigation has occurred"?
> Hm... "preserve data after navigation" seems like a possibility, but sounds an awful lot like "preserve log" - I doubt that'll help avoid much confusion,

I wasn't suggesting an name for the option, I was just stating what the option would be for. Such an option should exist, no matter how it is called.

> though it'd be useful for those who understand the problem as a workaround.
It doesn't look to me as a workaround, it looks to me as the obvious solution and the only decent one.


> Maybe a better option would be "break on navigation" where you could inspect
> anything you want to before resuming?
That would be another very useful (actually I'd say necessary) tool, but by no means an alternative to the possibility to preserve response data after navigation.
We need both.
Breaking may not always be a viable option (suppose there's a redirect and suppose the behavior of the server changes if more than a given time elapses from one navigation to another), and sometimes you just need to inspect data a posteriori (a break only gives you an opportunity, if you miss what you are looking for and then proceed, you won't ever have any other chance to inspect the data from previous responses).

I understand that by default response data is disposed of after you navigate in order to not consume memory unnecessarily, but it is simply plainly stupid that you cannot choose to preserve it.


> btw the least Chrome could do here is to display a more informative error message. 

Yeah, I absolutely second that. 
It should say "response data no longer available because we decided you wouldn't need it" (just kidding, but yes, the current message is misleading to say the least).
> Maybe a better option would be "break on navigation" where you could inspect

You could set the DevTools to break on the unload event. That should do exactly this.

> I can't believe this hasn't been done in more than two years.

Please notice the star count... only 18. So as far as getting this functionality prioritized for inclusion it isn't exactly high. Not many developers are showing the need for this so it isn't a top-of-the-pile request to be filled.
> Please notice the star count... only 18. So as far as getting this functionality prioritized for inclusion it isn't exactly high. 

OMFG Is that actually the criteria that is used for prioritizing issues? F***ing unbelievable.
Star count isn't the only thing that goes into prioritizing a request. It however is a factor for feature requests such as this.

Currently Service Worker improvements are under way. Those are getting top priority at the moment afaik. Why stop work on that new functionality to add a feature that not many developers are asking for? It doesn't make any sense.

I understand that this issue may be major to you and even hinder your workflow in some way. I am sorry about that. It is really frustrating when your most powerful tool isn't working the way you'd expect.
Matt: prioritization is hard.  Everyone has their favorite feature request, and there's always limited resources to fix things and build new things.  Star count does seem to be a reasonable proxy for how many people care about it, given this is the chrome dev-tools section.

Having said that, I also see that there have been 10 issues merged into this one so far, which seems like a lot (though I'm not that familiar with Chromium development). For the often-reported bugs, I'm of the opinion that if they are quick to fix, it's better to just fix them now than spend more time talking about them because they keep being reported.  Though at the least, it's maybe a sign that the title could use some tweaking to make it more searchable.

As far as actual solutions:
- better error message seems like something we can all agree on.
- suggestion: why not keep all responses < 1kb in size?  Most requests / responses I'm interested in are small ajax requests anyway, and it seems to keep the headers - the response body would add minor overhead, and wouldn't really be a dangerous memory leak for such small response sizes.  This would solve 90% of the problem for me.
It's ridiculous this isn't fixed yet. If preserve log is checked then the log should be preserved. How am I supposed to debug pages which redirect to other pages? As soon as another page is loaded the response data from previous pages is wiped. I have to dev with Charles Proxy.
Labels: -Type-Bug Type-Feature
You are free to take up the task and implement it yourself. Assigned status does not mean it is actively being worked on. With this being a feature request it is low priority and combine that with a low star count, it isn't getting any higher on the list. As stated in comment #26, pushing the DevTools forward for newer technologies is taking precedent.

Also on the note of "10 issues merged in" that is a red-herring. When issues are merged the star count from the other issues are added to the current issue. There are numerous reasons duplicate issues get created. Simply because one problem is reported 8 different ways doesn't mean the priority should change.
How is this a feature request and not a bug?
Obviously I'm a web developer, not C++ programmer. I'll buy whoever fixes this for the next Chrome release a case of beer. Should just be a simple if-statement to not throw away response body data when dev tools are open and Preserve Log is checked.
Labels: Restrict-AddIssueComment-EditIssue
Restricting comments since the comments being given are not on topic for the issue tracker.
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

-Anthony
Owner: ----
Status: Untriaged
Labels: -Cr-Blink
Labels: Cr-Platform-DevTools-Network
Status: Available
The ideal scenario is that with "Preserve upon navigation" we also retain XHR responses for inspection. 

Our team cannot make that happen without significant effort the browser generally treats navigations as entirely new contexts without much history of a previous page. It touches our multiprocess architecture, memory management and a whole swath of infrastructure concerns.
We'd like to get to this in the future, but it'll be some time.


In the meantime, the pause unload trick is going to be the best way to inspect the page before it's gone:

  window.onunload = function() {debugger;}



Comment 47 by caseq@chromium.org, Mar 18 2016

 Issue 595972  has been merged into this issue.
Cc: allada@chromium.org
 Issue 617205  has been merged into this issue.
Owner: allada@chromium.org
Status: Assigned (was: Available)

Comment 51 by caseq@chromium.org, Dec 14 2016

Cc: l...@chromium.org paulir...@chromium.org caseq@chromium.org pfeldman@chromium.org
 Issue 639274  has been merged into this issue.
Status: WontFix (was: Assigned)
Closing due to lack of priority / resources.

Sign in to add a comment