"View Source" window re-requests page if user has disabled the memory cache (and disk cache is disabled or page says to skip it)

NEW
Unassigned

Status

()

P3
minor
14 years ago
3 months ago

People

(Reporter: flammable, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: plan in comment 34 [necko-backlog])

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Whenever I open "view source" window, it once more loads the page source of
which I need. May be, sometimes it helpful, but in most cases it's not. Most
annoying is when I try to view source of the page which waas generated by server
requesting to a posted form, I always promted to repost data I've just posted.

If a page already was loaded and browser already has its source, what are needs
to load it again instead of just show?

Reproducible: Always

Steps to Reproduce:
1. Type in and load an URL
2. Right-click page and select "View source"
Actual Results:  
Loaded page source, which loaded actually twice - once in browser window and one
in view source window.

Expected Results:  
Loaded page source directly - like IE opens it in notepad, without downloading
it again.

Comment 1

14 years ago
works for me in Deer Park alpha 2
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050904
Firefox/1.0+

Comment 2

13 years ago
CHANGE SEVERITY from enhancement to normal.
CONFIRM BUG.

View source should show the source of the present page - not the source of the resource.

This is a bug not an enhancement. This is very buggy and unworkable for me as a user of this software, the view source simply doesn't work for me as it should, therefore I have to rely on other browsers.

This is a bug - not an enhancement request. Unexpected behaviour.
(Reporter)

Updated

13 years ago
Severity: enhancement → normal
(Reporter)

Comment 3

13 years ago
Still valid for Firefox 1.5

Comment 4

13 years ago
To add to the problem, when you view source this extra request does *not* send cookie information with it. So if you are viewing a page that requires the cookie to get the state (PHP Session state to be precise.) you don't even end up with the page you want!

I wish this could be bumped up in priority. It is hard to use as my default trouble shooting browser because of this.

Comment 5

13 years ago
I found a workaround in that when you do a select all, then view selection source, it'll display the source, but without the doctype headers.

the title of the source window becomes "view-source: - DOM Source of Selection"

So I'm wondering if we can use DOM source instead of re-fetching source when there's no cache or the page expired.

Comment 6

13 years ago
This is definately still around for Firefox 1.5. For example, if you go to a page where you've logged in, and wait past the auto-logout time then view source, you'll get the source of the "logged out" page, whatever that may be.

I'm running Debian GNU/Linux, so it's not like this is a platform-specific bug.

Why is there a need to do a separate request anyway? Surely the page source is available somewhere...

Could the bug reporter please mark this as something other than unconfirmed?
(Reporter)

Updated

13 years ago
Version: unspecified → 1.5 Branch
(Reporter)

Comment 7

13 years ago
> 
> Could the bug reporter please mark this as something other than unconfirmed?
> 

Sorry, but I haven't rights to re-mark this. Otherwise I'd have this already done.

Comment 8

13 years ago
Oh well, guess we have to wait then. (bugzilla shouldn't be presenting me with all these dropdowns to change the status of the bug if I can't actually do any changes...)

It's a pity this bug exists, because between it and the "View Selection Source", you can't actually get to view the _exact_ source that the browser received.

I will vote for this bug, if I have any votes that is.

Comment 9

13 years ago
Voting for this one - it's killing me right now.  I'm now forced to debug CGI work through other browsers (which sucks).

This bug existing in pre-1.0 mozilla, and was fixed years ago.  The fact that it's rearing its' ugly head is not good.

As everyone else has said, this is a MAJOR bug.

Comment 10

13 years ago
Looks like this was also reported as Bug 251231.

Comment 11

13 years ago
Bugs I've found to date relating to this:
Bug 251231
Bug 306916
Bug 307089
Bug 321291
Bug 340120

I'll bet there are more - this was simply a search in Bugzilla for "view source". 
*** Bug 362076 has been marked as a duplicate of this bug. ***
*** Bug 361038 has been marked as a duplicate of this bug. ***

Comment 14

12 years ago
still valid for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061207 Minefield/3.0a1 with latest updates ...

this seems (at least according to bugzilla) cause quite a few related issues, so someone should really fix this

Comment 15

12 years ago
And still valid at "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070323 Firefox/2.0.0.3", as a reminder.

According to the code it should work (though I'm not really sure what the code does, the comment suggests it should):

mozilla/browser/base/content/browser.js:2173:
  //
  // Get the 'PageDescriptor' for the current document. This allows the
  // view-source to access the cached copy of the content rather than
  // refetching it from the network...
  //
  try{
    var PageLoader = webNav.QueryInterface(Components.interfaces.nsIWebPageDescriptor);

    pageCookie = PageLoader.currentDescriptor;
  } catch(err) {
    // If no page descriptor is available, just use the view-source URL...
  }

So it expects to find it from the cache.  For me, about:cache reports (in brief):
Memory:
Maximum storage size: 	18432 KiB
Storage in use: 	27928 KiB
Disk:
Maximum storage size: 	10000 KiB
Storage in use: 	3 KiB

Not sure what's going on with using more memory than max.  Also, although the images on the tested page is there, the page is not.  The disk cache only has favicon.ico's in it.

Perhaps this problem is with the caching code, not the view-source piece.
What are the repro steps to see this error occur? Using the steps from the original bug does not reproduce using the current trunk build on Windows XP.

Comment 17

12 years ago
On linux, with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070603 Firefox/2.0.0.4, and default values for browser.cache.* (assuming changes in about:config are immediate):

1. load www.altavista.com
2. run tcpdump to watch traffic (careful on the filtering, since altavista could be pointing to a yahoo or akadns.net server)
3. select view source and see traffic in tcpdump

As I mentioned in a previous comment, I think it's because the page is not cached and the view source code is trying to pull it from there. We know the code is available because you select part or all of the page and choose 'View Selection Source' from the context menu, so where is that coming from?  Why wouldn't the regular view source use that?

Comment 18

12 years ago
why is this still "unconfirmed" ?

Comment 19

12 years ago
hm .. this is indeed fixed in todays trunk nightly

Comment 20

12 years ago
Confirmed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 F!refox/2.0.0.6

If it was in the trunk for such a long time, why was it not in a released version yet?!

Btw I sometimes get similar behavior when saving displayed images but that should be a different bug report although it might be the same problem...
(Assignee)

Updated

11 years ago
Product: Firefox → Toolkit
Duplicate of this bug: 427836
Duplicate of this bug: 340120
Duplicate of this bug: 321291
Duplicate of this bug: 412933
Duplicate of this bug: 417390

Comment 26

11 years ago
I don't have the permissions to do so, but for someone who does:

Can you please update this bug to show that it *DOES* affect current 3.x firefox?  This bug still references the now-ancient 1.5 (!!!!), but some of the recently-marked duplicates are complaining about current versions.

Updated

11 years ago
Flags: wanted1.9.1?

Comment 27

10 years ago
I've experienced this in Firefox 3.5.2 including Shiretoko 3.5.3pre (August 20, 2009), on both Macintosh OS X 10.4 and Windows Vista.

I put up a test case at http://selenetan.com/test/firefox-view-source-test.php . I've attached the source. The submit button makes a POST to the server, which generates a random number to make it clear when you're viewing a re-request. An 'Expires' header is set to "force" caching.

Steps to reproduce:
   1. Click "submit form" on the page.
   2. Select "View Page Source" from the View or right-click menu, or hit Cmd/Ctrl-U
   3. Page source window will prompt you to resend POST data

Expected: Page source window shows current source of page.

Bug 166786 describes the same behavior on SeaMonkey. When I tested in SeaMonkey 1.1.17, the bug did not appear.

Comment 28

10 years ago
The test on selenetan.com works fine for me on mozilla-central and on the Firefox 3.5.x branch.  The only way I could get View Source to show a repost dialog in 3.5.x was to disable both the disk cache (Prefs > Advanced > Network) and the memory cache (browser.cache.memory.enable).

Comment 29

10 years ago
The test on selentan.com works for me on firefox 3.5/linux too. However, I still do see the behaviour on other sites - I think it can be triggered when cookies are required for the page (see original notes on this bug).

Comment 30

10 years ago
Okay, I've confirmed that when at least one of browser.cache.memory.enable or browser.cache.disk.enable is true, the issue no longer appears.

It seems likely that at some point I disabled both of them using the Web Developer add-on's Disable > Disable Cache. I don't remember manually editing those values, and I checked my other add-ons, so it must have been through that add-on.

One thing: I thought the disk cache was enabled until I checked about:config for the memory cache setting and saw the disk cache setting highlighted. There's no explicit display for it in Prefs > Advanced > Network. There's a "Use up to [number] MB of space for the cache" display, which was still set to 50, but no check box for "Enable disk cache".
Duplicate of this bug: 392017
Confirming, retitling, & marking as applicable to latest trunk.

I think that *even if* both memory and disk cache are disabled, view source should not reload the page.  When you view source, you really really want to see the source of *the page you have right now*, not the thing that you would get if you re-requested from the server.  (This goes double because the-page-you-have-right-now might have come from a POST request that changed server state and shouldn't be repeated, and triple because apparently we lose your cookies in the re-request.)

Web developers commonly disable all caching so they can be sure that the cache isn't handing them a stale version of something they're trying to debug, and they're more likely than most to reach for view source, so this is not a silly combination of settings, either.  Also, per bug 392017 (which I just marked as a dupe of this) it bites you if the server sent cache-control headers that prevent all caching (which is normal for e.g. SSL pages containing private data).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Summary: "View Source" window requests page once more when opened → "View Source" window re-requests page if it isn't cached
Version: 1.8.0 Branch → Trunk
IIUC we should have the data required in the bfcache even if it's not in the necko cache, right?

Comment 34

10 years ago
I believe bfcache stores DOM, not markup.

Maybe we want browser.cache.memory.enable to not disable the memory cache entirely, but instead:
* Evict items as soon as they cease to be pinned
* Use the memory cache only to service requests for View Source (and other things using pins?)
Summary: "View Source" window re-requests page if it isn't cached → "View Source" window re-requests page if all HTTP caches are disabled

Comment 35

10 years ago
I'm not convinced bug 392017 is a dup of this bug.
(In reply to comment #34)
> I believe bfcache stores DOM, not markup.

For some web-development use cases what one actually wants out of View Source is a reserialization of the current DOM, so one can see what one's javascript has done to it.  But maybe that's more a Firebug thing.

> Maybe we want browser.cache.memory.enable to not disable the memory cache
> entirely, but instead:
> * Evict items as soon as they cease to be pinned
> * Use the memory cache only to service requests for View Source (and other
> things using pins?)

Sounds good to me :-)
(In reply to comment #36)

> 
> For some web-development use cases what one actually wants out of View Source
> is a reserialization of the current DOM, so one can see what one's javascript
> has done to it.  But maybe that's more a Firebug thing.
> 

Actually you can do that now.  Do Select-All, then right-click View Selection Source.

But I don't know how well that's known.  I only learned about it when I did view-source linkification...

Comment 38

10 years ago
View-source should not display the DOM. You want to view the response from the server, not the DOM which maybe was manipulated by an onLoad() function.

IMHO if a user disables the memory and disk cache he/she is not a l33t user.  A developer should set Browser.cache.check =1 to get a fresh page everytime.

What if firefox displays a warning like the POSTDATA warning that is it unable to display source due to cache being disabled and it is going to get it from the server.  Maybe something like:
“Firefox is unable to display the current source because memory and disk cache are disabled. Firefox will try to retrieve the page from the server.”
(In reply to comment #38)
> View-source should not display the DOM. You want to view the response from the
> server, not the DOM which maybe was manipulated by an onLoad() function.

Yes, I agree with this.

> IMHO if a user disables the memory and disk cache he/she is not a l33t user.  A
> developer should set Browser.cache.check =1 to get a fresh page everytime.

Do you mean browser.cache.check_doc_frequency?

In *my* humble opinion, even technically sophisticated users (such as web developers) should never have to dig through about:config and the sketchy MDC documentation of about:config to get the behavior they need.  about:config is for things that *only* Firefox developers should ever need to mess with; otherwise it ought to be in the exposed preferences.

> What if firefox displays a warning like the POSTDATA warning that is it unable
> to display source due to cache being disabled and it is going to get it from
> the server.

Only if we cannot fix the bug properly (i.e. save the response from the server for this purpose).

Comment 40

10 years ago
If I want to look at the DOM-generated version of the page, I'll use firebug, or select everything and use view selection source.

What I really want access to is the source as sent from the server.

This should be possible _regardless_ of whether the memory/disk cache are enabled or not. In fact, regardless of any setting at all.

It sounds like, from comment #34, that this bug is fixable properly. I think that if we had to implement the dialog suggest in comment #38, it should be considered be a failure to fix this bug.
I was about to report this when I found this bug. It's mighty annoying. One of the biggest failures of the open source movement is the fact that serious bugs like this can exist for four years without anyone fixing the problem. Totally ridiculous.
Serious bugs can and do exist for years in closed-source software without anyone fixing the problem, as well.  Yes, open source is supposed to do better, but open source is not immune to having too many bugs and too few people who know how to fix them, either.  And this is hardly the oldest serious open bug :-)
I would even say that this is "hardly a serious bug" really. It isn't going to get your machine owned or cause you to crash. It's annoying in certain circumstances. We have much higher priority issues and the need for people to submit patches for bugs that are lower priority.
Flags: wanted1.9.1?
I would say it is extremely serious. It could in the wrong hands result in a payment going out of a bank account twice. I can't see anything much more serious than that. Simply viewing the source on a page submitted as part of a form causes a reload of the page. OK, there's a warning that you are submitting a form again but that doesn't always mean anything to the end user.

Comment 45

10 years ago
Are "end users" disabling their memory cache? :(
It's an obvious thing to try if Firefox seems to be taking too much memory, for instance, even though the necko cache isn't the big memory hog.  Web developers  turn off every last cache they can find because (I am told) the "ping the server on every page load" toggle doesn't actually do what it says, or perhaps didn't at some forgotten point in the past, and who has time to mess with settings that do work?  Googling for "firefox memory cache" brings up tons of inconsistent, probably years-out-of-date advice on how to tweak the preferences.

So, uh, yeah.  They do.
Users do not need to be involved in disabling the cache, it's quite possible for the page to disable the caching without the user even knowing it has happened. That is why I think the description is somewhat missleading.

Comment 48

10 years ago
I don't think a page can disable the memory cache in a way that breaks View Source.  If pages can do that, it should probably be a different bug.

Updated

10 years ago
Summary: "View Source" window re-requests page if all HTTP caches are disabled → "View Source" window re-requests page if user has disabled the memory cache (and disk cache is disabled or page says to skip it)
Simple disable cache headers can and do do it here. Items such as Expires and Cache-control.

Comment 50

10 years ago
ian: please provide a server + script + set of gecko prefs to demo this. preferably with as few changes from fresh prefs to a firefox3.6 profile.

but as jesse indicates, if you can do this, *we* want you to file a new bug with those details, and then you can indicate the bug number for that here as a comment.

the mozilla engineers have decided to limit the scope of this bug to a single problem and a single solution.

if we didn't do this, we'd only need 5 bugs: "firefox crashes", "firefox is slow", "firefox uses too much memory", "firefox's shiny stuff looks wrong", "firefox looks/feels/acts old". because people would keep reopening and changing the direction of those bugs for their own purposes.
Component: View Source → Networking: Cache
Product: Toolkit → Core
QA Contact: view.source → networking.cache
Whiteboard: plan in comment 34
Duplicate of this bug: 655680

Updated

7 years ago
Duplicate of this bug: 789765

Comment 55

5 years ago
This also now affects the Firefox Developer Tools Debugger.

When you load the dev tools debugger, the page is re-requested without the current cookies. If you are logged into a site via cookie-based sessions (django commonly uses these), the debugger shows the source code to the login page (since the website thinks you're logged out).

Reproduction steps:
1) Login to https://bitbucket.org/ (or another django-based site)
2) Navigate to your profile page.
3) Open the developer tools (right click on the page and select "Inspect Element").
4) Click the "Debugger" tab in the dev tools.
5) The source code will show the source code of the login page, not the current page.

Comment 56

5 years ago
This is a very annoying and long-standing bug. Still present in Firefox 33.

Comment 57

5 years ago
(In reply to Jesse Ruderman from comment #45)
> Are "end users" disabling their memory cache? :(

My memory cache and disk cache are enabled and I am still affected by this. It is insanely annoying, it is impossible to reliably view the source of any page that requires post data.

Comment 58

5 years ago
I am now receiving this error on View Source. I don't recall getting it before.  Firefox 32.0.2

Comment 59

5 years ago
(In reply to George Mouchet from comment #58)
> I am now receiving this error on View Source. I don't recall getting it
> before.  Firefox 32.0.2

I had seen it before intermittently where the source was reloading, for quite some time now, but it was not until the other day that I saw the "resend post data" warning in the source view; I had never seen that before.

Comment 60

5 years ago
See my note above.
about:cache shows as below
After viewing about:cache, I could see that my disk cache was almost at the limit. I cleared my cache and refreshed the page.  The error went away.  There was plenty of memory available for cache space, so it should have used that, or else have some sort of automatic cleanup of the disk cache when it fills up.

memory
Number of entries: 	79
Maximum storage size: 	32768 KiB
Storage in use: 	324 KiB
Storage disk location: 	none, only stored in memory
List Cache Entries
disk
Number of entries: 	36243
Maximum storage size: 	358400 KiB
Storage in use: 	346003 KiB
Storage disk location: 	C:\Users\geomo_000\AppData\Local\Mozilla\Firefox\Profiles\baeo9cpk.George\cache2
List Cache Entries
appcache
Number of entries: 	0
Maximum storage size: 	512000 KiB
Storage in use: 	0 KiB
Storage disk location: 	C:\Users\geomo_000\AppData\Local\Mozilla\Firefox\Profiles\baeo9cpk.George\OfflineCache

Comment 61

5 years ago
Seth, does clearing your cache fix the issue like it did for me?

Comment 62

5 years ago
Maximum storage size: 	358400 KiB
Storage in use: 	345965 KiB

That did it! Thank you so much!

Comment 63

5 years ago
I've noticed that not only does this bug still exist in Firefox 34 

but it also re-requests the page WITHOUT COOKIES

ie. I can be logged into a website like a forum or blog, view the source of the page, and the source is the logged out version (which I never viewed while logged out)  Firewall clearly shows the page was re-requested without cookies.

I have both memory and disk cache enabled, that is not the issue.

This is a pretty big bug for developers that just want to see the source as it was transmitted for the page they are viewing.

Can this issue get any priority?

Comment 64

4 years ago
I access PACER the federal court system. I make copies of the dockets, including updates, so I can provide the copies to the public. This is legal since this is a federally funded system.

Firefox just recently started screwing up, big time, when I try to access the docket page source so I can copy the updated table entries. It tells me it doesn't re-request sensitive data.

Well, it shouldn't do a re-request. At all. This is what's known as "breaking the web"--view page source has been around since Tim Berner-Lee was a young'un. View page source should not make a re-request. 

This is actually costing me money, so I'm switching to a different browser until this is fixed. 

I'm using Firefox 33.1, Windows 7.

Comment 65

4 years ago
I completely agree with _ck_ and Shelley; this is a serious design blunder.  Viewing the page source should NEVER re-request.  I should be able to yank my network cable and still see the source of a page I've already loaded.

Firefox 34.0, Mac OS X 10.6.8

Comment 66

4 years ago
Clearing my disk cache helped the instance when I originally posted here, but my coworkers still get this error, regardless of their cache status. The annoying thing is, how hard can it be to fix this? Firefox needs to just store the source on page load, and show that...

Comment 67

4 years ago
I tried clearing my cache, and switching from the auto-managed 350MB to a manual 1GB cap.  Didn't fix it.

More to the point, it should be handled separately.  I understand that technically what we are asking for is a form of cache (the raw downloaded document before parsing) but each tab should keep this data, cleared only when you close the tab or browse away.  If this somehow goes against the browser's goals of being lightweight in memory, I would at least appreciate it as an advanced option we could turn on.

Comment 68

4 years ago
This bug is almost 10 years old and is still NEW?  Is there still no way to let 'view source' just look at the source that was already downloaded?

Comment 69

4 years ago
In firebug, go to the Net tab, then the All (or HTML) tab, locate the GET or POST request for the current page. Expand it, go to the Response tab, and there is the original source. If you right click the tab, from the context menu you can choose to open the raw source in a new tab, or copy to the clipboard. 

I imagine that some plugin like keyconfig would be able to create a scriptlet to enable this as a keyboard shortcut, but I don't have enough keyconfig experience to do it. NOTE that firebug needs to be opened first before you navigate to the page you want the source of
Whiteboard: plan in comment 34 → plan in comment 34 [necko-backlog]
Severity: normal → minor

Comment 72

3 months ago
I gotta say it's very annoying that instead of fixing it gets bumped down.
You need to log in before you can comment on or make changes to this bug.