ansaurus

Question

Why does Chrome show different page source?

Answer 1

A:

Are you referring to viewing source after doing an AJAX call? In that case the browser doesn't bother to update the original text version of the page it holds in memory (DOM). When you view source, the browser does not generate it from the DOM, it simply give you the original HTML document.

I can't see another way...

Mike Gleason jr Couturier 2009-11-17 05:11:40

If it's what you meant, Firefox has a developer toolbar that lets you see the "generated source".

Mike Gleason jr Couturier 2009-11-17 05:13:12

Answer 2

+1 A:

I just tried your example and it worked fine in Chrome dev-latest and Safari, and Firefox.

View this in Chrome and tell me what your source shows. If it isn't right, what's your version of Chrome?

When you go to view source, what URL is shown in the tab that shows you source. Mine shows : view-source:http://www.geekymedia.com/sotest.php

Rizwan Kassim 2009-11-17 05:16:43

Answer 3

+1 A:

Applying the "SELECT is not broken" rule:

The problem exists somewhere other than where you're looking.

ie. Chrome is not doing something it shouldn't - your page/logic is confusing chrome, or you're otherwise missing the broken piece of this puzzle.

Some things to do to try track down where the issue lies: 1. Try duplicate the issue in different browsers - using the current code 2. Try duplicate the issue in different code - start a new example from scratch 3. Post your results to these so we can help you further.

nailitdown 2009-11-17 05:20:28

What kind of busted ass text editor removes line breaks from user input.I'm not fixing this out of protest, because Stack Overflow is broken.

nailitdown 2009-11-17 05:25:13

It's called markdown, and there's a preview right underneath the edit box. Just sayin'.

Tim Lytle 2009-11-17 05:35:48

Not broken, just not plaintext. Stack Overflow text is written in Markdown format. Markdown requires a line break between paragraphs. That way you can wrap your lines of text to 80 chars and it won't mess with the flexible-width output.

Chuck 2009-11-17 05:36:57

"End a line with two spaces to add a <br/> linebreak:" is broken. Should Read: "End a line with a line break to add a line break".

nailitdown 2009-11-17 05:49:49

See also: principle of least assing about with the most fundamental user input conventions.Please sacrifice a left handed monkey to reply to this comment.

nailitdown 2009-11-17 05:52:05

Answer 4

A:

I've seen the same thing in a Ruby on Rails application where, on certain pages, Chrome displays the source of the 500.html page from the public folder instead of that of the page being viewed.

Now it's certainly possible -- likely even -- that there's an error in the page html or that the server is responding in a way Chrome doesn't expect, but that doesn't explain why Chrome displays the page correctly but displays the wrong source, or why other browsers (Firefox and IE) display both the page and the correctly.

So I don't have an answer, but let's not dismiss the question too soon, it's a good one.

paulbonner 2009-11-17 05:33:06

Answer 5

+5 A:

This is a caching issue... session_start() will issue several HTTP headers depending on the configuration variables session.cache_limiter and session.cache_expire or depending on what was set at run-time with session_cache_limiter() and session_cache_expire() repsectively.

The possible values for session.cache_limiter/session_cache_limiter() are:

`public`

Expires: (sometime in the future, according session.cache_expires)
Cache-Control: public, max-age=(sometime in the future, according to session.cache_expire
Last-Modified: (the timestamp of when the session was last saved)

`private_no_expire`

Cache-Control: private, max-age=(session.cache_expire in the future), pre-check=(session.cache_expire in the future)
Last-Modified: (the timestamp of when the session was last saved)

`private`

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, max-age=(session.cache_expire in the future), pre-check=(session.cache_expire in the future)
Last-Modified: (the timestamp of when the session was last saved)

`nocache`

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

The default setting for session.cache_limiter is nocache.

This at least explains the situation you described in your update.

Stefan Gehrig 2009-11-17 07:58:54

Answer 6

A:

In fact, i notice right now the same problem that paulbonner mentionned : Chrome : the source doesn't correspond to what the page show Firefox & IE : No problem

Diako 2010-01-19 10:48:15

Answer 7

+1 A:

Chrome doesn't show any source if the webpage is result of an PHP feed by form using POST method. That's really weird.

To check this, go to USCIS webpage:

https://egov.uscis.gov/cris/processTimesDisplayInit.do

and click any of the 3 [Submit] buttons at the right bottom of screen, either [Field Office Processing Dates], [Service Center processing Dates] or [NBC Processing Dates].

When you click, the selection (any) at left of the button will be transferred to the specific PHP (or other script) via POST method. Then, the PHP will create on-the-fly the html that follows, and you can see a table of processing dates on screen.

This screen is what Chrome can not show as source. Right Click and [View Page Source] will produce a blank page. Firefox, IE and Opera works without problem in here.

The problem is that to have the "source", Chrome will read the page again from the websource at the internet, rather than read the webpage from inside its buffer. As the webpage is created in real time by the PHP and have a standard URL, without re-sending the POST contents of the form, what comes back from the webserver is a blank page. In real, when clicking View Source, Chrome try to read again the webpage, but the webpage doesn't even exist, it is a result of the PHP output creating a real time html.

Firefox, IE and Opera works nice in this case, I suppose they read the webpage contents from inside its cache or buffers, rather then try to read the webpage again from the internet.

Now, if you use some Chrome tools (I use them), one ables you to convert Form POST to Form GET, so, when clicking any of the [Submit] button, the calling for the PHP will be carrying the arguments, such as "http://www.anysite.com/anyscript.php?field='value',field1='value1'...", as the Form GET works, using the "question mark" and fields and values along with the url being called.

Then, when the PHP (anyscript.php) runs, it will generate the output html screen, but will keep the same information at the address bar. Then Chrome is able to show the source, since Chrome will resubmit the address bar URL to get again the webpage, and it is carrying the GET arguments along, so Chrome works. But that is the wrong way to do it.

So, I found out that Chrome is the only one that resubmit the request for the html to be able to show the source, and it uses the contents of the address bar (URL) for that. I really don't think this is healty or correct. Problems like that will keep working.

See, I want to View the Source of what is on my screen, not what is on the internet far away server html, IF, the html really exist or was generated on the fly.

Google people, I love you guys, but please rethink this issue, that's really not good at all.

Here a simple test. Just upload the following to your favorite webserver, name it "foo_test.php" (for example) and call it from IE, Firefox, Opera and Chrome, you will understand what I said above.

<?php
if(!isset($_POST['submit']))
   {
   echo "<form method='POST'><input type=submit name='submit'></form>";
   } else {
   echo "You Can't view the source of THIS LINE using Chrome.";
   }  
?>

Wagner

Wagner 2010-10-08 18:53:32

ansaurus

tags:

views:

answers:

Why does Chrome show different page source?

`public`

`private_no_expire`

`private`

`nocache`

related questions