| Issue 523: | View source after POST command isn't what you expected (View source forces page reload) | |
|
250 people starred this issue.
Comments by non-members will not trigger notification emails to users who starred this issue. |
Back to list |
Sign in to add a comment
|
Product Version : 0.2.149.27 (1583)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3: OK
Firefox 3: OK
IE 7: OK
What steps will reproduce the problem?
1. Do a POST action which result in different content, but the url stays
the same.
2. View Source(Ctrl+U).
3.
What is the expected result?
A exact code(html) representation of what you see in your tab.
What happens instead?
It shows the code of the page where you pushed the 'POST button', but not
the code of the page were you are at that moment.
I understand why, because a new tab opens with: 'view-source: url...'. So
the POST command isn't executed again. A option for 'show real source' is
desirable.
Sep 12, 2008
#1
henrik.n...@gmail.com
Sep 15, 2008
It looks like the source is fetched from the page cache on the client and may be older than the rendered page. Not very developer friendly. In fact the display source may not even be from the correct page as the bug report states. For example, if source => <html><body>hallo</body></html> rendered => hallo chrome displayed code => <html><body>hallo</body></html> and I change the source: source => <html><body>bye</body></html> rendered => bye chrome displayed code => <html><body>hallo</body></html> There is a simple workaround for this: Click on the refresh button in the *source* window.
Sep 15, 2008
NB: Refreshing the source seems to resubmit the page *without* the originally posted data (which means that in most cases this is not useful).
Sep 16, 2008
(No comment was entered for this change.)
Cc:
fin...@chromium.org
Labels: -Area-Unknown Area-BrowserUI
Sep 16, 2008
i can confirm this when a page is built as a result of a <form method='post'...> and i want to have a look into the source, it tries to re-load the page WITHOUT the form-variables that are posted
Sep 25, 2008
Confirmed again. Almost the first thing I tried while testing my perl web app. Source does not show what is displayed in the page after a POST.
Oct 30, 2008
Confirmed again. I've had to use firefox any time I am developing with post variables being sent to the page. It's really irritating and necessary for a web programmer.
Dec 11, 2008
Where's the UI for voting for a bug? This one is a show-stopper!
Dec 11, 2008
(No comment was entered for this change.)
Cc:
-fin...@chromium.org
Dec 29, 2008
Issue 2644 has been merged into this issue.
Jan 17, 2009
This is incredibly frustrating as a web developer... Obviously the rendered code is already in memory, can't we just display that instead of displaying an unposted version?? This is a huge problem, as a post variable can determine whether you look at something like a homepage or possibly something COMPLETELY different... sometimes we use GET to do this, but I'm not sure why webkit's using a non-WYSIWYG version here when the one everybody needs is a gimme
Feb 12, 2009
Workaround: - Right-click page, click 'Inspect Element' - Select resources tab - Refresh page, resubmitting form - Select page in the Inspector resources tab And you can view the page source from the POST.
Feb 12, 2009
There lies another bug - the source is not shown in the Inspector.
Mar 2, 2009
Issue 8103 has been merged into this issue.
Mar 18, 2009
This depends on internal b/951391, I think. I'll have a look at that and file a bug here on code.google.com.
Status:
Available
Owner: --- Labels: -Area-BrowserUI Area-BrowserBackend Mstone-X
Mar 19, 2009
This may be related: URL: http://tuw.stcsrl.info/ The website is build using XML data and transformations. View source displays only the XML data while the inspector shows what is expected. This happens on any subpage regardless of you POSTing a form or not. Chrome 2.0.170.0 (Officiel version 11755)
Mar 27, 2009
Issue 2587 has been merged into this issue.
Apr 3, 2009
Apparently in order to view page source Chrome attempts to fetch the page from website anew. This presents problem * with POST requests * in case the webpage on server has changed since you opened it in your browser * in case the connection to server is slow and you hate waiting extra 10+ seconds to view the page source In any case I'd like to add an extra suggestion here: to have two different "view source" options 1) "Display original source" --- page source as it was downloaded from internet 2) "Display current source" --- page as it has been parsed by browser and later altered by JavaScript. Basically same thing as when you click "inspect element", only without the need for gazillion of clicks to actually find something...
Apr 15, 2009
(No comment was entered for this change.)
Blockedon:
10570
Jun 28, 2009
I think Firefox has something similar to that called "view dom source", but again that only comes up when you select something.
Jul 17, 2009
#19: Nice idea! #21: It's "view selection source" And yes, this should be fixed for the sake of web developers.
Nov 15, 2009
Issue 27681 has been merged into this issue.
Nov 30, 2009
Need this to be fixed! It is the only thing stopping me from completely ditching firefox!
Dec 3, 2009
Took me 20 minutes to see this was a bug and not a problem with my code. This is one of those common sense things that you never think about because it shouldn't happen. I can't believe this bug has been here for 15 months.
Dec 17, 2009
Took me 1 hour grrr... :(((((((((
Dec 17, 2009
Replacing labels: Area-BrowserBackend by Area-Internals
Labels:
-Area-BrowserBackend Area-Internals
Jan 15, 2010
Same here, I still end up using Firefox a lot to check my source code. It's also bad because since it re-sends the request, it might do something unwanted like update data on the website. This needs to be fixed, whatever it takes. Send this bug report to your developer friends and ask them to *star* it or do something so we can get a higher priority on this.
Jan 23, 2010
IMHO this is a significant bug. Very confusing...
Jan 23, 2010
I experience this bug as well. I must add, I am absolutely amazed this bug has been open for nearly two years. It is a total showstopper - it prevents us entirely from using chromium to web development, and forces us to resort back to using firefox. Which I definitely am not happy about. Please fix.
Jan 29, 2010
People, how long could this possibly take to fix? You rolled out an entire extensions interface, extensions themselves, bookmark sync, and took care of literally hundreds of bugs that were FAR more complex than this, but you can't display the damn cached source that's ALREADY IN MEMORY? PLEASE FIX THIS. NOW.
Feb 25, 2010
Confirmed again. Switching to FF every time I need to see the source is very frustrating.
Feb 25, 2010
One of the reasons why I switched back to FF. The other one was better supported AdBlock Plus and the plugin framework in general.
Feb 25, 2010
I second comment 19 -- having an option at the top of view-source to "view current source (parsed)" [includes after javascript, etc], "view current source (unparsed)" [no javascript, etc], and "view raw source" [current behavior] would be great. If ultimately this went as far as Opera's view source (where you can change the source and apply the changes to the webpage) that'd be great, too.
Feb 25, 2010
I agree, tigerhawkvok... I love making changes to the DOM with the developer tools, but we probably couldn't edit the source because the browser would likely have to re-parse the source code. Regardless, this would be cool because sometimes the elements inspector doesn't show you everything you need or let you add text arbitrarily!
Feb 25, 2010
I think that this can currently be worked around by going to the Page Menu --> Developer --> Developer Tools. You can view the source both as a DOM tree in the Elements tab (you can even manipulate attributes here) and as raw HTML in the Resources tab. That said, I'm investigating a fix for this bug in my spare time.
Cc:
rse...@chromium.org
Feb 25, 2010
Thanks rsesek, The problem is that Chrome parses and corrects the elements if there's any problems with code nesting and tag overlap. Since many of us are using Chrome as a development tool, we want to see the INcorrect code so we can amend our scripts to output proper HTML. Since Chrome is fixing it for us, we have to use another tool like Firefox to get a grasp on what's really going on. Thanks for looking into this.
Feb 25, 2010
rsesek @37, that is the same as the "inspect element" option available by right- clicking the page. Thanks for looking into this, though. I think all the varieties of viewing source that have been mentioned here have their merits (for example, the current implementation makes it easy to just refresh the source and look at server-side script changes in- source, without going through the page first). Hopefully we can come up with a good option here.
Mar 1, 2010
Issue 34307 has been merged into this issue.
Mar 26, 2010
Issue 34873 has been merged into this issue.
Mar 26, 2010
Issue 23914 has been merged into this issue.
Mar 26, 2010
Issue 39473 has been merged into this issue.
Apr 5, 2010
Submitted: Sep 03, 2008 Today: April 05, 2010 Is this a joke?? Maybe i'm the crazy one for thinking something like this should of been fixed before it was even released. It's view-source for christ sake, how do you screw that up and then NOT FIX IT?
Apr 6, 2010
This is an open-source project. We report bugs, and then a member of the community has to fix it. Report further information, sure, but don't bother getting angry if you aren't willing to pick up and fix this bug yourself.
Apr 6, 2010
There are several extensions that provide this functionality: https://chrome.google.com/extensions/detail/gbkffbkamcejhkcaocmkdeiiccpmjfdi https://chrome.google.com/extensions/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm https://chrome.google.com/extensions/detail/hhlpjofmehafeaiaiflnddnfgnnpibgf
May 12, 2010
I too would love this bug to be fixed. Not sure if there is some confusion around, since other people are talking about things like "view selection source" (a separate issue). But in short, this is a request for the "view source" command to show the raw HTML that was sent back from the server for the current request. If a POST request produces different HTML, then that different HTML should be shown, not the original. (Side question: in this case, is Chrome requesting the original page from the server again, or is it using a cached version?) Incidentally, it would certainly be beneficial if, when reloading the "view-source:http://... page, it reposted the same data - obviously with the same warning you get for regular pages.
May 19, 2010
@47 - actually, none of those extensions provide the requested functionality. Their "view source" appears to simply provide a resource to the built-in "view source" functionality. I am unable to find any extension that works, in fact.
May 19, 2010
@49 - Try using "View Generated Source" from the first link (Pendule). Or, the last link, which requires you to select the entire document to view the POST source.
May 19, 2010
@50 - No, they're still not what's expected - for Pendule, it's almost like the source has been parsed somehow when viewing generated source? for instance, on a script that generates the literal string 'SELECTED' for a select option in a form, Pendule changes the output of the script at that position to 'selected=""', and also changes < and > to < and >. The last link does the same thing. I can verify with other browsers that the actual output is all uppercase in this example... When I view source, I'm expecting to see the actual output of the server, not something that has been parsed.
May 24, 2010
(No comment was entered for this change.)
Status:
Started
Owner: rse...@chromium.org
Jun 23, 2010
Issue 45669 has been merged into this issue.
Jun 25, 2010
Issue 47453 has been merged into this issue.
Jul 27, 2010
(No comment was entered for this change.)
Cc:
-mal.chromium
Jul 29, 2010
Issue 43515 has been merged into this issue.
Jul 29, 2010
Issue 43908 has been merged into this issue.
Jul 29, 2010
Adding search keywords: cache, cached, caching, duplicate, duplicates, request, requests, reload, reloads, refresh, refreshes
Summary:
View source after POST command isn't what you expected (View source forces page reload)
Aug 6, 2010
What's the status on this "bug"? Is there any plans to change this behavior?
Aug 14, 2010
Issue 51713 has been merged into this issue.
Aug 14, 2010
Issue 44180 has been merged into this issue.
Aug 20, 2010
There was a tip to use the resource tracking feature then look at the documents section to view the rendered source code. This has worked for me (although more steps than simply right clicking to view source). However I noticed something today that could pose a problem. I went in to copy and paste the "view source" from the resource tracking documents and noticed that the HTML tag warnings were also included in the copy, e.g. "Unmatched center tag". I would like to see either the ability to turn these messages off or avoid them being copied into the clipboard. Of course ideally I would like to just right click on the page to view source and get the expected source code like I do with other browsers.
Sep 6, 2010
Issue 54613 has been merged into this issue.
Sep 7, 2010
This is the most annoying aspect of Chrome, which prevents me - any many other developers - from using it for development. Correct View source is a must.
Sep 16, 2010
In numerous reports throughout this issue, one point is being made consistently: this issue is a major pain for *developers*. Some sort of 'devel' (web developer) reference is make ~ 13 times on this issue (eg. @1,@7,@11,@22,@28). @46 makes mention about the 'open source' aspect of this project, and subtly infers that community feedback may also include code contributions. While I have not personally followed any of the links to the chromium issues, or looked at the project source, I find it interesting that the strong tilt of 'developers' reporting the issue has not yet reveled a champion from the community :^) Since this issue isn't getting the attention it deserves, perhaps it can be approached from a different POV: have one of the add-on tools provide the option to view the *current* source. In fact, I suggest that the "web developer extension" would be the perfect area to provide this [absent] functionality. This could be implemented as a choice/button/toggle within the plugin, or if possible, override the core 'view-source' behavior. just some thoughts.
Sep 16, 2010
Yes, this problem primarily hurts developers... _web_ developers. C++ isn't a popular language among web developers. Now, if Chrome was written in javascript, php, python, perl, etc. then all of these developers commenting on this bug might be able to help.
Sep 16, 2010
Thank you specialk, couldn't have said it better myself :-) Not about to learn [more of] C++ on top of the 7 scripting languages I use on a day-to-day basis... that's what the Chrome devs are good at.
Sep 23, 2010
Ok, I have only read as far as about comment 30, but I have found a workaround which is better than any of those suggested up until then. If you click on the spanner next to the "Add to Favourites" star icon, then click "Developer", it should display the current source even after a post - ok so its long having to expand all of the elements, and I havent looked into this much but it looks to be quicker than having to use Firefox. Thought I should let everyone know in case it hadnt been found. Regards, Richard
Sep 23, 2010
Richard, The problem is that the Developer view shows the HTML code after the DOM has been parsed and manipulated by both the browser and the scripts in your page. In addition to this, Chrome automatically closes and moves tags where necessary, thus modifying your code structure. The whole point to viewing source with post data is to view an unadulterated view of server output, so we can amend the scripts in case improper code has created a problem. For now, this is not possible, and is the reason this issue exists.
Sep 23, 2010
Thanks for clarifying that staticfive. I noticed I had a little cross with a 2 next to it in one corner - I assumed (wrongly) that this meant Google hadnt corrected anything, and that I was viewing an unaltered version of the code. When you say it MOVES tags where necessary, could you give me an example? I mean it seemed to be the source of the actual page I was viewing - and if thats the case then tags may be moved for any customers who are using Chrome to view my site. Does this "moving tags" thing directly affect how the page looks, or just the code you see when inspecting it? If the latter then ignore the paragraph below. I know all the tags should be nested correctly in the first place - and it is very rare for me to get a tag in the wrong place or forget to close a tag - but my point is that if I were to test my site in Firefox and found it displayed perfectly, but Chrome moved a tag which dramatically affected the display, then any customers using Chrome would get a naff page. Regards, Richard
Sep 23, 2010
Chrome would only move/close the tag if it's improperly nested. I will also close a tag if it's nested inside an element where it's not allowed. For instance: <p>Some text<p>More Text</p></p> was automatically changed by Chrome to <p>Some text</p><p>More Text</p><p></p> Check it out in your code inspector--It's not the way the raw page output looks.
Sep 23, 2010
On the "use Developer Tools" note, I usually find <ctrl>+<shift>+i an easier way to access it. (Also, "Developer" has been pushed into a Tools sub-menu in the later versions 7.0.517.8). The x with the 2 next to it in the bottom right corner of developer tools - is the number of errors in the page. Click it for details. And yes, it is an incomplete solution as detailed by staticfive. Thanks for your great explanation, better than I would have said it.
Sep 27, 2010
Everyone, please follow on to issue 10570 and vote for it as well, since it's the one that Google marked as blocking this one; therefore, if they fix 10570, then they'll fix this one here too. https://code.google.com/p/chromium/issues/detail?id=10570
Sep 30, 2010
Issue 57510 has been merged into this issue.
Oct 29, 2010
Issue 61292 has been merged into this issue.
Nov 4, 2010
Issue 61881 has been merged into this issue.
Nov 24, 2010
Issue 64376 has been merged into this issue.
Nov 24, 2010
Well I think the fact that 4 issues have been merged into this issue (in a row, in just 2 months) says it all - Google listen to your users!!! Developers are important too, ya know...
Nov 30, 2010
Issue confirmed in latest version as of 2010-11-30. This issue completely voids the purpose of having a "View Page Source" option in the right click menu at all, and in addition IT PISSES OFF ALL DEVELOPERS! If you're not going to do a developer option right Google, don't do it at all. I'm ok with using Firefox to do all my debugging in, but this is still very annoying. Maybe someone can release a Chrome add-on that does it right. I'm going to go looking right now infact.
Nov 30, 2010
@northcott.michael, there are some extensions which help (read up to comment #47) https://code.google.com/p/chromium/issues/detail?id=523#c47 but they're not as good as it would be to have this work as expected.
Nov 30, 2010
Or you can try this extension which is much more light-weight: http://members.iinet.net.au/~bertdb/ryan/ViewSourceWith/help.html
Dec 1, 2010
Or, if you really a web developer, you can always turn on the inspector.
Dec 1, 2010
@chu121su12: So you are not "really a web developer" if you don't use the inspector? That sounds a bit stupid, even for someone who is "really a web developer", don't ya think?
Dec 1, 2010
@chu121su12, your comment, whether you intended it so or not, was quite rude. The point of this bug is that we want to view-source of pages after post. Yes, there is the inspector. No, we don't always want to use it. The inspector is good for testing styling changes, measuring elements, stuff like that, sure. But sometimes all I want to do is view the source of the page. The full, unmodified by inspector, source. And I'm *sure* others have their own reasons. Over 200 people have starred this issue. That says something.
Dec 1, 2010
Well, you can really see what happen if you debug your code like that. As for the post-related problem, I like to output them below my web pages so I don't need to inspect the document. And in other's website, if I really want to see the post data, I might as well use firefox to do further analysis on the website. I don't do that often, though.
Dec 1, 2010
Well put hahanottelling!!
Dec 1, 2010
hahanottelling: Exactly ! There is a lot of reasons why would someone want to just simply look at the generated UNTOUCHED code after POST. I agree there is no reason to be rude. This seems like an easy way for Chromium developers to implement, can someone responsible post an update to this issue ?
Dec 1, 2010
This is insanely unintuitive behaviour and I'm very surprised it STILL hasn't been fixed, let alone that somebody thought it was a good idea in the first place.
Dec 1, 2010
I dont mean any rudeness. I was just responding to "IT PISSES OFF ALL DEVELOPER." I do view the page source at some times, and I know I cant view the after-post page. That's why I starred this issue.
Dec 1, 2010
@hahanottelling - Just to make sure you know - You can go to the Resources tab of the Developer Tools and see the unmodified source of the page, exactly as Chrome received it. With Chrome 8 or earlier - you have to turn on Resource tracking first, but with Chrome 9 it seems to be enabled by default (and the Network tab needs some kind of enabling instead, which gives you more information about the request\response headers, cookies and timing). That is not to say that the simple "View source" after post should not be fixed, of course. That is just to say that there are native alternatives within the browser, that no hope is lost.
Dec 1, 2010
thanks @phistuck hadn't tried that for anything but images. works nicely.
Dec 1, 2010
2 year old bug!!! can u believe it?
Dec 1, 2010
@Jottil.gang believe it! time for someone to patch it. I'm down, any takers?
Dec 1, 2010
I spent some time thinking about this bug, and I have a fairly simple solution in mind: From Browser::ViewSource(), we should essentially duplicate the current TabContents, leveraging the code for DuplicateTab(). However, we should only duplicate the current NavigationEntry when cloning the TabContents. Finally, we should modify the copied NavigationEntry to change its virtual_url property to be prefixed with view-source:. This should have the effect of causing the new tab to render the source of the old tab, even if the old tab's contents were generated via a form POST. The NavigationEntry holds within it a unique identifier for each form submission. That identifier is used to index the cache to locate the response from the form submission. @rsesek, Are you still working on this bug?
Dec 1, 2010
(No comment was entered for this change.)
Owner:
pfeld...@chromium.org
Dec 1, 2010
I have/had a WIP patch, but I've been busy with a constant stream of Mac FE work. There's two things that I ran into when working on it: 1. The new TabContents needs to be in the same SiteInstance so that the original WebHistoryItem can be accessible. 2. There's some edge case in which the original WebHistoryItem isn't used by WebCore, so it creates another one, which bypasses the cache and doesn't produce the desired results. I hadn't devised when this happens exactly.
Dec 7, 2010
Oh my god. It's finally getting fixed? I love you! :D
Dec 15, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=69246
------------------------------------------------------------------------
r69246 | pfeldman@chromium.org | Wed Dec 15 02:30:12 PST 2010
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.h?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents_delegate.cc?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents_delegate.h?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.cc?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/render_view_context_menu.cc?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/browser.cc?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/navigation_controller.cc?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/navigation_controller_unittest.cc?r1=69246&r2=69245&pathrev=69246
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/browser.h?r1=69246&r2=69245&pathrev=69246
View source after POST command isn't what you expected.
BUG=523
Review URL: http://codereview.chromium.org/5716003
------------------------------------------------------------------------
Dec 16, 2010
(No comment was entered for this change.)
Status:
Fixed
Dec 16, 2010
"fixed"? Does this mean we will soon see the fix in the general Chrome releases? What's the workflow from now?
Dec 16, 2010
It will get to the Dev Channel in a week or so, then it'll become a part of M10 (Chrome 10 stable milestone).
Dec 16, 2010
Awesome to see this done! Thanks
Dec 16, 2010
yay!!! Thank you!
Dec 30, 2010
Issue 68302 has been merged into this issue.
Jan 25, 2011
Please fix it !!! => and DON'T grab the source code from the SERVER !!!! Cache it, and show it to us !! PLEASE think one minute about it, nod with your head for 10 sec., an spend 5 Minutes to implement it .. problem solved !
Jan 31, 2011
Issue 71415 has been merged into this issue.
Feb 4, 2011
Issue 69262 has been merged into this issue.
Feb 16, 2011
=> and DON'T grab the source code from the SERVER !!!! Cache it, and show it to us This sounds like an ideal solution for a number of other reasons, as well. View Source should show the source that was actually used to render the page, not a source of another HTTP request (which was only made to show source)
Feb 18, 2011
Still don't fixed! Google I ask more from you!
Feb 18, 2011
This bug is closed as Fixed in comment #102, please check the status before sending emails to >200 subscribers.
Feb 18, 2011
After 2 months, this "fix" is still not even in the dev channel. I am using Chrome 11.0.672.2 dev and the problem still persists. Here's a quick and easy way to test this: 1. Go to http://www.graphpad.com/quickcalcs/randomn1.cfm 2. Fill out the form to generate a random number. (1 column, 1 row, from 1 to 100000) 3. Submit the form. (this is a POST request) 4. Check the source code. You will notice that the random number does not appear anywhere in the source. That's because the source code is of that webpage without submitting a POST request at all (i.e. if you go to that URL directly and not by submitting the form). So how long does it take for these fixes to get applied?? Is there somewhere we can check what stage this is in?
Feb 18, 2011
I agree, some kind of timeline would be nice. Over 2 months ago, it was said it would be in dev channel in about a week. I have been using the dev version; haven't seen it yet.
Feb 27, 2011
Thanks for everyone reporting that it still does not always work. It turned out, that a bug in duplicating tab tracked under crbug.com/17261 was not letting this fix shine. Duplicate tab is now fixed and you should expect this feature working in the nearest dev channel release (~1 week). Then it'll hit stable with Chrome 11M. Sorry for this taking so long. More context: the content state of a page was not propagated into the navigation entry until further navigation or a scroller adjustment. So on the beta channel today, if you move your scroller on a page with POST result or click a link on it and go back, you will see proper source for that POST submit. I am currently working on fixing it for subframes (View source frame) + making Chrome never issue GET upon View source for GET requests (separate cache issue).
Feb 28, 2011
I just use the Developer Tools feature to view the "posted source" - that works perfectly! Shortcut is Ctrl-Shift-I - this has now made Chrome my browser of choice. Firefox just takes too long to start up these days, very annoying!
Apr 4, 2011
This was fixed in the development version, and has since been reverted for some reason in the last month or so? The 'inspect element' link from the right click menu was also removed, making it a right pain to find elements on a page in the dom browser. Yet we still have 'View Page Info' which is utterly useless, it doesn't even give info such as file size, or the URL in the case of a frame.
May 26, 2011
just want to through in my 2-cents that this is a double show-stopper for me as well.. 1) not showing the POSTed page source forces me to use FireFox for development 2) having the source reload means that when I return to a page in history and attempt to view the source it changes. Not a show stopper, but a "Doh!, that sucks.." moment. Please, just show the current HTML source that is in cache for the immediate page! Also, "View Page Info" IS useless.. Showing the certificate info is nice, but the main reason I click the page info is to get a URI in a frame/iframe..
Jun 14, 2011
Ditto to the complaints. This is totally unacceptable behavior. A page submitted w/request parameters will be resubmitted w/the same parameters, even if they are no longer appropriate causing all sorts of odd behavior (duplicate submissions in particular). It's bad enough as a developer, but if my clients are using Chrome, yikes.
Jun 16, 2011
Re comment 118 and on: This bug is not present in the current stable [12.0.742.100 (Official Build 88853)] or canary [14.0.794.0 (Official Build 89286) canary] builds.
Aug 26, 2011
I am using the latest chrome stable (13.0.782.215) but still see this issue. Whenever you click on Ctrl-U to view page source, chrome reloads the page.
Aug 29, 2011
Come on. How hard could it be to just allow us to view the exact source code that was just downloaded, without pulling down another page than the one we actually clicked view source on? Why make us go through the resource tracking and all those sub-menus and stuff, only to still see some modified version of the code?
Oct 6, 2011
This well known flaw just cost me hours of debugging effort, when there was no bug. I had to use (shudder) IE to confirm that my code was correct, as fetching a new version from the server does not produce the same result by design. Ironically, in my case it was Google conversion tracking code that was not displayed on the reload of the page, as you would not want it to! View source means "view the source of this page" -- how can anyone possibly think it means "view source of the next refresh of this page", which is of course useless in some cases. Yet another "feature" of Chrome that means to me that Chrome is still a toy, but not ready for actual use in the real world. Hard to believe.
Nov 2, 2011
"View source" is supposed to pull up the cached file currently being rendered in the window, not download a fresh copy! Chrome's current bogus method of "view refreshed source" is a useless waste of my time because A) Re-POSTing form data alter data on the serve in an undesired manner and/or retrieve different results, and B) I often have to debug pages which load slowly because every refresh triggers an intensive server-side process (e.g. compile and generate a LARGE video and display it in the web page) and unnecessary repeat refreshing triggers additional processes while I wait a few years for the _HTML_SOURCE_ to load. If a page looks like it didn't render correctly, being able to view the source *as it was generated by the server* is CRITICAL, so don't go telling me to use one of the "view RENDERED source" features. But, really! How damned hard is it to "view source"? If nothing else, just point to the cached HTML file and send it to NOTEPAD.EXE. That's what IE used to do.
Nov 3, 2011
I can't understand why this is set to "Fixed"? This is clearly not fixed, and it is VERY annoying. Yes, maybe you can see the source by going through annoying hoops, but the default behaviour is NOT as expected. I know myself and my colleagues keep having to fire up firefox just to easily debug projects. I love chrome, but could you please take the time to make this work?
Dec 12, 2011
This issue is NOT fixed. It has NEVER BEEN fixed. I love love love Chrome - but this is the most annoying thing that I run into as a developer EVERY SINGLE WEEK (sometimes, every day). Go use the "view source" feature in ANY other browser - FF, IE, Safari, whatever. NO other browser does a fresh request just because someone has asked to "view source". When you "view source", it should be showing you the source code that has ALREADY BEEN DELIVERED TO YOUR BROWSER. It's hilarious that the Google engineers are supposedly highly-vetted geniuses, but no one there can figure this out after YEARS of notifications that it is a problem.
Dec 21, 2011
This bug is not fixed. Please FIX this. It's a 4 year old bug, come on!
Jan 26, 2012
Not sure if this will help all circumstances, and it's not quite as convenient as a direct "View Source", but Inspect Element:Resources:Frames Folder:[filename]Folder:Stylesheets:[filename] (it's not as bad as it sounds, just a couple clicks) This shows me the pre-POST source without the reload message. And while we're talking convenience, I like Opera "Validate Page" as a direct link from the right click menu.
Jan 26, 2012
Update Comment 129: Just found that the inconvenience of the extra clicks is minor because the Inspect Element source window automatically updates when you reload the page if you just leave it open. And installed the validator. Not sure if it's as nice as the right click to W3C in Opera.
Mar 15, 2012
Status says "Fixed" but it has NOT been fixed. This bug alone makes Chrome unsuitable for web dev work.
Mar 27, 2012
I have confirmed this bug
Apr 23, 2012
This is a horribly annoying bug. It is impossible to view the source code of any page after a form submit without having to resubmit the page. Viewing the source should not have anything to do with submitting the page. It should display the source code as seen in the browser.
Jun 26, 2012
This issue is not fixed.
Oct 9, 2012
Still present and as annoying as 4 years ago. Any plans on fixing this one?
Jan 28, 2013
Still not fixed as of 24.0.1312.52 Come on Google, support developers who want to use your products.
Mar 10, 2013
(No comment was entered for this change.)
Labels:
-Area-Internals Cr-Internals
Blockedon: -chromium:10570
Jul 30, 2013
Really. Fix it already...
Jul 31, 2013
This bug is still affecting Chrome 28.0.1500.71. pfeldman, your fix doesn't seem to have propagated. Could you please take another look at this issue?
Sep 16, 2013
Chrome 29.0.1547.65 - the bug still exist! Why it's so difficult?
Sep 17, 2013
If my users ever do a view-source they actually trigger a resend and that can screw things up.
Sep 17, 2013
Sorry guys for the regression. It has been recently fixed: http://src.chromium.org/viewvc/blink?revision=157253&view=revision The fix will arrive in Chrome Stable 31. Meanwhile you can use Ctrl-Shift-I to browse source without resubmission.
Owner:
eus...@chromium.org
Sep 17, 2013
It's so great to hear about this fix! Until Chrome 31 comes out, is there an equivalent hotkey for OSX? Ctrl-Shift-I doesn't do anything, and Cmd-Shift-I appears to be some kind of email hotkey. When I press it, Outlook opens a new email with the title of the page as the subject, and a link to that page in the body.
Sep 17, 2013
@eustas, r157253 is "Reland Fix form resubmissions happening silently. This reverts commit 9f3fcfea463d525af6b525318998edb72c09a7e1. BUG=263508" But Issue 263508 is already Fixed and Merge Completed for M30 builds. Does that mean this is fixed in Stable 30 or 31?
Sep 17, 2013
Oops... ignore that auto-link. That's Blink rev. 157253, like the link from Comment 142
Sep 18, 2013
Looks like fix was really merged into M30. Om Mac try F12 to open DevTools. Unfortunately, DevTools won't show page source if it was opened after page is loaded. So, you should open DevTools before submitting post request.
Sep 18, 2013
@eustas - It works for me without opening before submitting. For example, I had Outlook.com open for a while. I pressed F12, went to the Resources panel and selected default.aspx - the source code was shown. The Network panel does indeed need the Developer Tools feature to be active before submitting.
Sep 18, 2013
Clarification: resource returned by POST request won't be shown.
Labels:
-Mstone-X -Cr-Internals Cr-Platform-DevTools
Sep 23, 2013
Issue 296168 has been merged into this issue.
Sep 23, 2013
Issue 296168 has been merged into this issue.
Jan 4, 2014
In every other browser on the planet, the "View Source" function displays the source of the currently rendered page. It doesn't re-fetch the page from the server. This is the EXPECTED behavior. Why are Chromium developers forcing an unexpectedly different behavior in the Chromium project and all browsers based on it? I find this to be highly annoying, especially there had been a form submission where Chromium/Chrome would ask me to do the form submission again. It makes no sense to me. No other browser would ask me to submit the form again when trying to view the source... Can't believe this is being pushed as a "feature" when it has no rationale...
Feb 15, 2014
Thank you, this bug/feature/whatever makes Chrome unusable for development. Back to Firefox.
Feb 17, 2014
There are some trade-offs. By preserving fetched page we pay with memory. Commonly you should use DevTools to see page source. PS: I understand, that there are scenarios when it is too late to open DevTools...
Feb 17, 2014
I don't think memory usage is a valid reason, memory on PCs isn't a bottleneck usually. On the other hand, if dev tools have the correct page source why isn't the same displayed for view source?
Feb 17, 2014
I did not see memory problem: other browser can, why Chrome cannot? at least can be added some option for enable pre cache source, that developers can enable
Feb 17, 2014
jbti, Chrome stores the DOM in memory, but not the original page source. That would be additional information to store.
Feb 17, 2014
I completely agree that this should be an option available to developers or power users, among the advanced settings... could be worded in such a way that regular users won't bother.
Feb 25, 2014
Is "memory" really an issue to opt not to store <100kb in a process that routinely uses over 1GB?
Mar 13, 2015
This apparently persists in Chrome 41 (ERR_CACHE_MISS when trying to see source). |
||||||||||
| ► Sign in to add a comment | |||||||||||