User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5 When I view source for a page, that page is reloaded (i.e., new requests are made, etc.). That creates a number of problems: 1) I can't view source of an already-loaded page when offline 2) I can't view source of pages that require cookies (say, a shopping cart) since the view-source request does not apparently have cookies 3) It makes debugging ANY state-based page nearly impossible, since reloading the page changes the state. This is really a big problem. Reproducible: Always Steps to Reproduce: 1. View source Actual Results: Camino loads the page as if you had told it to load that URL from scratch, losing any state-based code. Expected Results: Camino should actually display the source of the page that has already been loaded! As a quick example, log in to your favorite webmail program. View source for your inbox. Instead of seeing the source code for that page, you are seeing the source code for the login page. Now imagine you were writing a webmail program and trying to debug that inbox page in Camino.... frustration....!

This sounds a lot like bug 332102, although ISTR that isn't the only bug on this issue (the other may be a Core bug that I'm not finding at the moment).

Gmail (the given example URL) uses frames, so this is a dup.

This is not just for frame-based pages. This happens with the shopping cart system I am developing on my computer. There is not a single frame used throughout. What happens is that I add an item to a cart, get a funky cart readout, and am tryng to analyze the source but when I view source I get "no items are in your cart". If I reload the page in the browser, I can still see the items in my cart. Even more interesting, when I go to the site where the stable version of the code is running (thompsonedition.com), and view source on a shopping cart, there is no problem. Could my problems, then, be due to the fact that I am accessing a page being served locally? Safari and Firefox both act normally for me -- that is, I can view the source of a shopping cart and see the items in it. So, I'm certain there's a bug in Camino which is not related to frames.

It would be very helpful if you could create a publicly available (or locally servable) testcase of a non-frame-based page demonstrating this problem.

I will allow outside access to my local web server for a period of a few hours (which can, of course, be extended). Here is the link to the site I am working on, served from my computer. http://80.34.147.135/~mg/ A walkthrough: 1. From the home page, click "Browse Catalog" 2. Choose "Horn" under "Browse Accessories by Instrument" 3. Add any item to the shopping cart. 4. View source -- this will give you the following error: "The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel." 5. You can reproduce this error without postdata as well. Click on the "Shopping Cart" link to view your cart again (this time no postdata is being passed). Now view source. Look carefully -- you'll see "No items exist in your cart -- go ahead and add some" ... Even though items are clearly in your cart. Please let me know when you have seen this, so I can stop forwarding port 80 to my laptop.

I've used VPN, proxies, etc., to route myself so that when I access my computer from the outside world, using Camino, I still get the same problem -- view source reloads the page. So this has nothing to do with the fact that I'm accessing a locally served page. Also I've verified that Firefox, Safari, etc. do not have this problem. Unlike the frame-based bug, if I create a simple PHP page that prints out the time, and view source, I do not get a reload. Could this be related to cookies? I have found another example where view-source reloads, with no frame. http://thompsonedition.com/search.php?q=mozart View source -- you will see that another request is being made, with the message "Waiting for thompsonedition.com..." at the bottom of the status bar.

(In reply to comment #6) > I have found another example where view-source reloads, with no frame. > > http://thompsonedition.com/search.php?q=mozart That's expected: Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache And looking at your local version, all the pages there have the same. If we can't keep a cache, we can't show source from a cache. INVALID.

You're absolutely right about the headers.. I'd looked at the comments under Bug 332102 ("view frame source triggers reload.."), particularly Comment #2, and thought that the cache-control wouldn't be an issue. I've done some further tests, and indeed on the simple page that serves up a timestamp, it is reloaded if those cache-control headers are sent. So Camino is perhaps doing the "right" thing by following those directives. However, Fox and Safari are doing the "wrong" thing by allowing you to view the source anyway. I definitely prefer the "wrong" behavior here. There is a very good reason to allow source-viewing no matter what the headers -- web developers. Is there a good reason to insist on following the headers? Or is it possible to get the source from the DOM tree instead of a cached copy?

Odd; as far as I can tell we are using the same Gecko APIs Firefox does for view source (in the non-frame case), so I'm not sure why we would be behaving differently, but looking into core bug histories more it definitely looks like view source is intended to be able to access existing versions of no-cache pages as long as the page is still open. Re-opening for investigation into what we are or aren't doing.

I looked at this a bit, and we are correctly loading by page descriptor, so I'm not sure why this isn't working. It may be that we need to do something explicitly to pin the no-cache pages while we have them open, but that seems unlikely given that, as I understand it, BF-cache depends on the same backing store.

FWIW, the one place I visit regularly and which sends those (comment 7) headers, bugzilla.neooffice.org, has never worked with bfcache. With Firefox and the LiveHTTPHeaders extension, I can verify a new request is issued when going back (with Camino, I just know going back feels slow :P ), yet viewing source there in Firefox does not cause a new request to be issued.

I am seeing this same bug or a related bug on a page that comes through many redirects. The page is protected by Shibboleth <http://shibboleth.internet2.edu/>, which uses a bunch of redirects for checking authn/authz. first to a "WAYF" (where are you from) service, which allows users to select which institution should authenticate them, next to a cosign authentication page (potentially other authentcation, but cosign in this case), and finally back to the target page. Viewing source shows the source of the WAYF page. Normally, this page is only accessed at most once per browser session, and a cookie is saved to store the result. None of the pages have frames. I notice that the cosign page includes: <meta HTTP-EQUIV="Pragma" CONTENT="no-cache">, but the target page doesn't have a cache control header as far as i can tell. Firefox shows me the correct source of the target page. All three pages are saved at http://people.internet2.edu/~danno/caminobug/ From what I can tell, once the authentication has succeeded, future page loads that are protected by shibboleth/cosign appear to be OK. I can probably provide someone access to this to see it in action. I am using 1.6b2 on powerpc 10.4.11

Dan, is there any way you can set up a live demonstration of this? Barring that, please e-mail Stuart, Smokey, or myself privately with details on how to access the site that exhibits the bug (so that no private information is compromised in this public bug). cl

I don't know exactly how i'd set up a live demo but i'm willing to give it a shot. Can VNC have multiple viewers attached to the same session? Or any other suggestions as to how? sorry for the slow reply, bugmail going to a mailbox i don't always check (which i'll fix).

FYI, I just tried this with "Version 1.6.3 (1.8.1.16 2008080311)" on intel and can no longer reproduce the behavior I describe above. The "WAYF" and cosign services are unchanged since then (I manage them).

This is still a live issue and affects Firefox as well...

This doesn't sound like a dupe, since no-one here mentioned disabling browser cache (although it's hard to tell for sure without understanding why it's broken for us currently). We should retest once bug 307089 is fixed and see if that miraculously fixes us, though.

This was my logic: Here, it is reported that view source reloads any page that was transmitted with HTTP cache control headers that instruct us not to cache the page. There, it is reported that if the cache is disabled by user configuration, view source reloads everything. Hypothesis: view source reloads any page that it cannot find in the necko caches, no matter why it is missing. If so, both bug reports are symptoms of the same underlying bug, hence duplicate. I don't mind marking this one a dependency of that one instead, though.

It's certainly possible, although the reason this bug stayed in Camino instead of being kicked elsewhere years ago was that because with the same test-pages and default settings, Camino exhibited the bug while Firefox did not. It's also possible that Firefox was ignoring the no-cache headers at that point in time (see the speculation in comment 8) and is not anymore, leading to this bug now being manifest in both apps. Given the history of this bug (and of other bugs where something didn't work in the embedding case for reasons other than those in the XUL case or a bug later appeared in the XUL case and its fix did not fix the older embedding case), I definitely want to keep this open until we can test the fix in a Camino build, but setting a prospective dependency is fine.

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]