Closed Bug 307089 Opened 19 years ago Closed 5 months ago

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

Categories

(Core :: Networking: Cache, defect, P3)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: flammable, Unassigned)

References

Details

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

Attachments

(2 files)

PHP server-side test case for bug
882 bytes, text/x-php
Details
Error_Incorrect_contents_fetched_please_reload_2022-01-03_22.30.30.mp4
988.93 KB, video/mp4
Details 
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.
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+
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.
Severity: enhancement → normal
Still valid for Firefox 1.5
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.
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.
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?
Version: unspecified → 1.5 Branch
> 
> 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.
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.
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.
Looks like this was also reported as Bug 251231.
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. ***
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
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.
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?
why is this still "unconfirmed" ?
hm .. this is indeed fixed in todays trunk nightly
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...
Product: Firefox → Toolkit
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.
Flags: wanted1.9.1?
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.
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).
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).
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".
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?
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
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...
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).
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.
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.
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.
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.
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
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.
This is a very annoying and long-standing bug. Still present in Firefox 33.
(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.
I am now receiving this error on View Source. I don't recall getting it before.  Firefox 32.0.2
(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.
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
Seth, does clearing your cache fix the issue like it did for me?
Maximum storage size: 	358400 KiB
Storage in use: 	345965 KiB

That did it! Thank you so much!
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?
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.
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
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...
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.
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?
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]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Severity: normal → minor
I gotta say it's very annoying that instead of fixing it gets bumped down.

Happened to me just now in Firefox 83.0 (64-bit) on Windows 10.

This is still occurring in Firefox 85.0 (64-bit) on Windows 10.

Seemingly with random pages, trying to view the source is instead showing the source of the login page for my app, as though the cookie isn't transmitted with the source request. However, after reading the comments here, I checked the Disk Cache and found it was maxed out with only 8k of free space left.

After manually deleting the Disk Cache files (about:cache), the page source is again showing correctly.

Can the title be updated to indicate that cookies are not sent on the re-request? Severity P3 does not seem to reflect the fact that you can't view the source of pages that require you to be logged in.

(In reply to mfishe from comment #75)

Can the title be updated to indicate that cookies are not sent on the re-request?

That's a symptom, not a cause, and should not be added to the title. OTOH, the title is already incorrect, so, I'm not sure it would matter. People have been tolerating this bug for 16 years now – so, in other words, there's zero incentive to fix it and, consequently, it won't be fixed. Just keepin' it real...

Anyway, the problem is simply that once the cache memory is maxed out, the older entries are not deleted to make space for new entries. Clearing the cache manually works 100% of the time for this issue and you can then immediately view the source of the page(s) that was/were problematic. For a dev machine, though – one where you might need to be able to see page source regularly – it is a hassle to have to keep clearing the cache, so, I disabled caching entirely. And now every page's source is showing correctly without fail. Here's the configs I used:

browser.cache.disk.capacity = 0
browser.cache.disk.enable = false
browser.cache.memory.capacity = 0
browser.cache.memory.enable = false

Sidenote: Amazon Prime now has a hard time starting up movies and it usually takes a couple refreshes before a movie will stream, although it does stream without glitching once it's started. Pandora will not work in this state at all. And FF seems to be hogging a lot of extra resources and requires more frequent restarts to keep it snappy.

Firefox 91.0.2, 16 years later still shows login screen source. Common guys...

FWIW I'm not comfortable with the distinction many seem willing to draw between "web devs" and "everyone else" here. It implies that the remedy being sought is something that only should matter to a web dev, which I'm afraid is bunk. There are actual real-world examples above from people who are not developers but just have their reasons to need to read the static source of the page they've been served.

It's no good to say, here in this secluded spot, that users need to purge their caches beforehand if they definitely don't want this to happen to them. Even if by chance they eventually find this information squirrelled away here, by then it is usually too late. It's a situation that shouldn't arise in the first place.

I'd go as far as to say that a source-view that requires the page to be re-requested is not what anyone wants, because the content may be different for any number of reasons - and even worse, that variability is something the viewer may not even be conscious of, so as such what's presented is misleading to the uninitiated. Absent a full fix for this issue, I'd actually advocate for the re-request not to be automatic, but rather to present an advisory with a confirmation dialog if the user still wishes to proceed.

This bug is almost old enough to enlist in the military. Then it will be old enough to buy booze. Then it will be old enough to collect social security.

Long story short: it's not getting fixed.

I just observed this behavior in Chrome today, so that's disappointing.

This seems as if it was fixed in Firefox version 92.0, and continues to be fixed today (95.0.2). Whether it was accidentally or on purpose, who knows. The latter would obviously be preferred.

(In reply to Jan Kyu Peblik from comment #81)

This seems as if it was fixed in Firefox version 92.0, and continues to be fixed today (95.0.2). Whether it was accidentally or on purpose, who knows. The latter would obviously be preferred.

I cannot confirm this.

When following my reproduction steps in Comment 55, when trying to load the Main Thread > bitbucket.org > account/settings > (index) debugger source code, it shows "Error: Incorrect contents fetched, please reload." in the debugger source code window.

Using: Firefox 95.0.1 on Ubuntu 20.04

(In reply to Daniel Roesler from comment #82)

Seems to work as desired for me, as just tested in Firefox version 95.0.2 on Windows 10. The Debugger tab shows the expected source and not the login page source. The 'profile page' for step 2 from comment 55 I have used is 'https://id.atlassian.com/manage-profile/'. Please advise if another address should be tested against. (I can also test on Ubuntu if we continue to have differing experiences. It would surprise me if the OS-specifics of the build would be at issue, but I suppose such things have happened before.)

(In reply to Jan Kyu Peblik from comment #83)

Please advise if another address should be tested against.

Attached is a screen capture video (Error_Incorrect_contents_fetched_please_reload_2022-01-03_22.30.30.mp4) showing the error.

(In reply to Daniel Roesler from comment #84)

I do see that same behavior over here. My observations are:

To be clear, this is to do with the Debugger part of the Web Developer Tools pane, and not the ordinary View Source system as per this bug's title. The ordinary View Source system does not appear to exhibit this undesired behavior at this time. It's possible you will have to file another bug for this (if this current bug is ever looked at by another developer, anyway).

This page seems to be heavy JavaScript nonsense, and roughly coded at that. I'm afraid I have limited understanding and interest, but offhand it looks like the JavaScript on which the page rendering depends attempts to act upon, for example, events that would only take place during page load, and which would therefore not necessarily be available just by opening the Web Developers Tools pane. It seems possible to me that this JS could by "design" not be compatible with this feature of the Debugger system that works with so many other more ordinary pages. It could be a fundamental, feasibly unavoidable side effect of using so much client-side code.

Anyway, I'll leave further comment on your particular Debugger issue to others in future. Again, the View Source system appears apparently resolved at this time, and that was my own interest. Best of luck.

(In reply to Jan Kyu Peblik from comment #85)
To be clear, this is to do with the Debugger part of the Web Developer Tools pane, and not the ordinary View Source system as per this bug's title. The ordinary View Source system does not appear to exhibit this undesired behavior at this time. It's possible you will have to file another bug for this (if this current bug is ever looked at by another developer, anyway).

Just to clarify that statement, as it is not immediately clear.

  • This bug (bug 307089) is to do with the fact that using the 'view source' feature will cause the page to be reloaded, rather than showing the source that was fetched in the original page request. It does not cover the source tab in the debugger at all and it does not cover error messages or other incorrect renderings of the source. Comment 81 indicates that this issue may well be resolved now, and this bug is awaiting further confirmation of that.

  • The issue reported by Daniel Roesler is related to the the debugger source tab and therefore should be logged as a separate bug (though, based on comment 85, it may be a site-specific issue in which case it may not be resolvable).

Severity: minor → S4

The severity field for this bug is relatively low, S4. However, the bug has 11 duplicates, 32 votes and 55 CCs.
:kershaw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(kershaw)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(kershaw)

This bug is still relevant. Today, I wanted to view source on a private page on my site but instead got the login screen.

If you disable all the caches (especially the in-memory cache), then re-requesting the page for viewing the page source is expected behavior. If you want to view the HTML source with cache disabled, you can open the devtools (F12 or right click -> Inspect).

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: