How to prevent Chrome from refreshing page when viewing source?

20

2

When viewing page source in Google Chrome, the browser opens a new tab and basically pastes the URL in with the view-source: prefix. This is undesirable.

As a developer, I may include some diagnostic output that is only visible in the source after submitting a form. When Chrome Refreshes the page to view the source, it makes this information disappear.

Is there anyway to prevent this behavior?

Note: I'm familiar with the "Inspect Element" option. This is just not an adequate stand-in for viewing the raw page source of the exact page you're looking at.


A quick test script

<pre>
  <?= print_r($_POST, true) ?>
</pre>
<form action="" method="post">
  <input id="foo" name="foo" value="bar" />
  <input type="submit" />
</form>

After clicking the submit button, the page shows

Array
(
    [foo] => bar
)

If you view page source, you will see an empty $_POST output

<pre>
Array
(
)
</pre>
<form action="" method="post"> 
  <input id="foo" name="foo" value="bar" /> 
  <input type="submit" /> 
</form> 

Update

Apparently this bug has already been submitted. Sigh...

If anyone knows of a good work around, I'd greatly appreciate it.

macek

Posted 2010-08-06T19:04:59.247

Reputation: 5 157

The people there do not understand that the source is not kept in memory (due to minimalism) but manipulated. You should see the comment http://code.google.com/p/chromium/issues/detail?id=523#c47 as that seems a nice idea too...

– Tamara Wijsman – 2010-08-07T09:10:48.343

Answers

12

From the bug report page, the workaround mentioned in comment 12 works: In the Developer Tools, enable Resource Tracking. (If it was off, enabling it will resubmit the request that generated the currently visible page, either POST or GET.) In the list of Resources, you can click on the main page to see the source code as it was returned by sever the for both POST and GET requests.

enter image description here

enter image description here

enter image description here

enter image description here

enter image description here

More information

I ran some tests using a simple php file that showed the request method used and a POSTed value, a proxy server log to see which requests Chrome was making, and the chrome://net-internals/view-cache/ prefix to see what Chrome was caching.

When you use the View Source command, Chrome shows the source of its cached version of the page, and it only caches pages requested via the GET method.

If you're looking at a page that you've previously requested using GET and POST, then only the GET version is cached. Using the View Source command won't re-request the page, but will show the cached GET version, not the currently visible POST version, if any.

If you're looking at a page that you've only requested using the POST method, then using the View Source command will cause Chrome to look in its cache, find nothing, request the page using GET, cache it, and show the source of that.

Bavi_H

Posted 2010-08-06T19:04:59.247

Reputation: 6 137

Nice discovery! – Tamara Wijsman – 2010-08-09T17:46:54.717

1Chrome has changed a lot since this answer but it's basically the same: open dev tools, ensure that network traffic is recorded and find the request that was logged in the Network tab. In the case of redirected requests you can check "Preserve log" or "preverse log upon navigation" to not erase the log with each new sync request. – Jon z – 2013-12-26T15:48:28.100

1@Jonz after realising this folly I am already disliking Google Chrome. For e.g. I needed to check the page source of Thank you page of E-commerce website (page loaded after user makes a successfull payment, for checking the firing of GTM code). Now on load of the page, I simply unset the necessary session and again on reload if the session is not found, I redirect the user to home page. So if I try to use Google Chrome hack, I am never able to view the page source, because it can only resend the GET and POST request, but it can't reset the session. Hence I would suggest use "Inspect Element" – Abhishek Madhani – 2014-06-04T12:37:30.417

1@AbhishekMadhani I'm not sure that you meant to reply to me, but I'll repeat what I wrote in a comment below - it seems that, as of Chrome Canary 37, a new network request is not sent when you view the source. – Jon z – 2014-06-12T18:25:57.500

2

Good question - and somewhat disappointing to read all those "this is wrong" or "this won't work" comments. This behavior makes the "View page source" feature useless for development in many cases.

There's an extension called "Quick source viewer", which appears to actually show the source of the currently loaded page (I haven't tested it with POST requests though).

basic6

Posted 2010-08-06T19:04:59.247

Reputation: 2 032

0

I'm sorry to tell you, but this is against the current nature of browsing and debugging in a browser...

The original source is not kept in memory, but is parsed and transformed into a parse tree as fast as possible, this to prevent useless memory usage. Thus, any debugging information you hide in the source is lost and must be explicitly requested. In the so-called Web 2.0 sites, elements also change and that is the reason the inspection is like that...

Solution 1: Fiddler Web Debugger allows you to inspect HTTP traffic,
this allows you to see the debug information from your last request.

Solution 2: Embed your debugging information or append it at the end,
or maybe show it as a pop-up or in another awesome way that doesn't disturb your lay-out.

Tamara Wijsman

Posted 2010-08-06T19:04:59.247

Reputation: 54 163

It's worth noting that the current behavior is actually quite useful for viewing the source of quick-redirect pages. Simply prepend view-source: to the url manually. That said, there are a million other ways to do this (e.g. curl) and this doesn't outweigh the benefits of view source acting as proposed by the OP. – Dan – 2016-06-27T21:02:11.600

13TomWij, "this is against the current nature of browsing and debugging in a browser..." this is just plain inaccurate. Current versions of Firefox and Safari both behave as "expected". In fact, because I've used these features in other browsers, I've come to expect them in Chrome. Keeping a couple KB of plain text for the original source in memory should be no difficulty. – macek – 2010-08-06T19:44:24.583

Google Chrome is known for its minimalism. ;-) – Tamara Wijsman – 2010-08-07T09:04:13.057

It's accurate, why keep comments or old code if your HTML code changes? – Tamara Wijsman – 2010-08-07T09:05:11.470

I don't know why the previous downvote came, but mine was because you didn't make any attempt to answer the question asked. – TRiG – 2013-10-07T16:12:18.117

@TRiG: At the cost of keeping things in memory, which on the first time also requires you to do a refresh; and yes, it does answer the question, because the options do not require page refreshes. I still prefer to run Fiddler or some other tool than to increase the already high memory usage. Since there was no previous downvote, I guess it was yours only... :) – Tamara Wijsman – 2013-10-07T20:48:32.837

My downvote came just now. Your comment asking why the downvote? is from three years ago. – TRiG – 2013-10-07T21:17:06.320

3This is demonstrably false. In Chrome you can save the original source of the page (Save page as) without doing a second request. This is what should be displayed when I "View Source". The current implementation is highly undesirable. For example when viewing the result of a POST. View source currently does a GET to the same location, showing an entirely different page. View source should always show the state of the page at the current request, NOT a future request. – Chris – 2013-12-17T12:22:35.507

Yes, but that is obtained from the cache; not from memory. – Tamara Wijsman – 2013-12-17T14:27:58.277

6No doubt, and that is where View Source should read from also. A new request is simply misleading and wrong. – Chris – 2013-12-18T16:11:55.597

Old question but I just came across it. View Source is an old hammer and it is not the right tool for the job anymore. Why do you need to see this information in a new browser tab? The proper way to do this in the current era when we have robust resource tracking in dev tools is to find the request in the network history of the current tab and examine it there. – Jon z – 2013-12-26T15:47:01.123

Did you mean to reply to the question? I'm not suggesting view source; in fact, I'm agreeing with you in the very first sentence of my answer. – Tamara Wijsman – 2013-12-27T11:38:54.280

2@Jonz Are you arguing to remove the View Source function altogether? I'd support this if the only alternative is the current broken implementation. But why can't we have both? Clicking through the network logs in the dev toolbar is a great option to have when you need that level of information, but if you just want to see the source for the current page it seems overkill. – Chris – 2014-01-02T17:18:00.373

@Chris I'm saying that (when dev-tools are closed) the browser has no need to retain the document source. The implementation you're asking for would require for every tab to remember its source, just in case the user decides to view it. A world class browser will save memory every chance it gets, so of course Chrome will make a new request (which may or may not be cached according to the rules of HTTP) rather than storing extra data per tab that will most likely not be used. If you're debugging the site and want to trade performances/resources for tooling, then use the dev tools. – Jon z – 2014-01-16T20:45:17.833

@Chris it looks like you get your wish, I'm currently using Chrome Canary 37 and, according to Charles proxy, in this build a new network request is not sent to the server when you view the page source (with or without dev tools open in the original tab). – Jon z – 2014-06-12T18:24:01.103