Firefox 29 back button will not return to previous form
Previous screen is a form for searching and the results returned. Clicking on a "more info" button moves to the next screen and shows more info. The "back" button will not return to the previous screen, giving the message, "document no longer available".
Firefox is standard vanilla install. All other major browsers return properly to the previous screen. If this cannot be corrected, we will be forced to abandon FIrefox and recommend to our 46,000 customers to move to another browser, especially when using our website.
To duplicate this problem, go to www.mybfl.com/search.php, search for a book, and when displayed, click on the 'More Info' button. Clicking on the Firefox "back" button illustrates the problem.
선택된 해결법
Yes, Firefox 32 is when this behavior began.
I just went in and checked Tools->Options->Override Automatic Cache Management and for the moment at least, the problem has disappeared.
Thanks, hope this solves the problem.
문맥에 따라 이 답변을 읽어주세요 👍 11모든 댓글 (16)
This is caused by Firefox honoring the instructions of the page not to cache or store it, so every reload requires another request to the web server. (See attached screenshot)
There might be a way to override this using an add-on, but in the short run, the best strategy is to open the links in a new tab or new window using one of these methods:
- Ctrl+click or middle-click (scroll wheel) => open in a new tab
- Shift+click => open in a new window
- right-click menu also has these options
글쓴이 jscher2000 - Support Volunteer 수정일시
Thank you for your response. If I understand you correctly, the problem is with our website's presentation to Firefox. How do we keep our website pages from instructing Firefox not to cache or store the page?
We are not aware of having provided that kind of instructions and we are not doing an https.
Thanks for your help.
The home page (index.php) comes with the same headers, so it may not be limited to search results.*
I'm not an expert on this but I think there are three places to check:
(1) In your php scripts, look for any header() directives at the beginning of the file.
(2) In the root directory, look for an .htaccess file that may contain cache-control headers.
(3) Check httpd.conf for cache-control headers. This may not be accessible on shared hosting services.
* However, Firefox only displays that dialog if the page you're trying to go back to was generated by a POST request.
글쓴이 jscher2000 - Support Volunteer 수정일시
Here is the content of .htaccess:
- comment spam
ErrorDocument 503 "Temporarily unavailable" RewriteEngine on RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} /email/log.php RewriteRule .* - [R=503,L]
It appears none on the above is relevant to anything other than when taking down a website for maintenance and returning a 503 to search engines.
All of our web pages have the same headers/trailers, ie:
require_once "std.php"
<web page scripts>
require_once "trailer.php"
Moving from any page to another allows a return to the previous page using the Firefox "back" button unless the previous page contained a form (search, logon).
The problem seems to be the form on the previous page. It is as if Firefox is afraid it cannot safely fill in the form (ie, the page has not been saved "as is"), but which is actually what we want.
It does not matter what Firefox settings we could apply as we cannot tell all of our customers to whom we have recommended Firefox, "By the way, you have to make this setting to get it working like it used to work."
We need a way for our webpages to signal, "Yes, by all means cache and copy!"
We do not seem to have an httpd.conf file, but I will pursue the possibility of it affecting us with our hosting company.
Thanks, Jack
Could you check inside std.php for any header() lines?
Checking the httpd.conf file content, there are no caching instructions other than where to cache SSL data and for how long. Firefox seems to think there is a security problem by caching/copying the page.
How do we turn that off? What can we add to what file so Firefox treats pages with HTML forms like any other page?
The error description does make it sound like a security issue, but since it is an HTTP page, it isn't really about security.
I'm pretty sure those headers are being sent by your web server; by default, Firefox is happy to cache pages generated by a POST, whether they are send over a regular connection or a secure connection.
One option might be to send headers instructing Firefox to cache the page for a certain amount of time, e.g., 60 minutes, to see whether that overrides the no-cache headers. I can't experiment with that at the moment, I would need to research/test it first.
Nothing like "header()" in std.php or any other php script (I did a grep). The first lines of std.php are:
<meta name="google-site-verification" content="S-KAkQLVtW8mHkOuwlrU2y_x5_a39oPxiSitp99UzZQ"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 90) echo "<meta http-equiv="refresh" content="$Refresh">"; ?> <meta http-equiv="Lang" content="en"> <meta name="description" content="Books For Less - New and Used Books"> <meta name="keywords" content=""> <title>Atlanta's Largest Independent Bookseller</title> <meta name="description" content="Your Atlanta bookstore - buy, sell and trade new and used books in Gwinnett County, Suwanee, Buford, Lawrenceville, Sugar Hill, Alpharetta, Fulton County and the surrounding area. Textbooks, novels, bibles and more. Stop by today!"> <link rel="SHORTCUT ICON" href="www.mybfl.com/images/favicon.ico"> <style> [ bunch of style stuff ] </style> And, all the pages work except for the one that has the HTML form for searching on it. I tried the logon form page and it does move backward fine. So it is not necessarily a form thing. How do I send a header instructing Firefox to cache?
I added the line:
<meta http-equiv="cache-control" content="cache, store, public" />
but still got:
Document Expired
This document is no longer available.
The requested document is not available in Firefox's cache.
As a security precaution, Firefox does not automatically re-request sensitive documents. Click Try Again to re-request the document from the website.
Yes, the important headers are sent first before the HTML document even starts. The std.php include and the meta tag cannot override them. The workaround will require some PHP code at the very top of search.php.
What needs to be sent before the HTML headers and will it affect setting cookies?
Cookies have their own header, expiration date, and so forth. Those are not affected by the page's cache settings.
Could you check the first response to this StackOverflow question: Setting up Expire Headers with PHP. It mentions the exact headers sent with your page as matching either of these settings:
session_cache_limiter = nocache -- in your PHP configuration session_cache_limiter("nocache"); -- in your search.php script
If you have the second line in your script, you can remove it or edit it. If it's in your configuration file, the suggested override is to start your search.php script with a new line:
<?php session_cache_limiter(false);
Does that work?
If you want to create global settings, this article sets out what to add to .htaccess -- except in your case, you would put php in the "2 hour" category:
http://www.askapache.com/hacking/speed-site-caching-cache-control.html
I haven't tried that myself.
If you need to send individual cache-control and expires headers from PHP for finer control, I haven't looked up the syntax, but I'm sure you can find it with some searches.
Thank you very much. I tried adding the line:
session_cache_limiter(false);
to our std.php as the first php line, but that did not fix it.
I then pulled our php.ini file and found :
session.cache_limiter = nocache
and changed it to:
session.cache_limiter = public
and that immediately fixed it.
Thank you again. We can continue to recommend Firefox as the browser of choice!!
This is caused by Firefox honoring the instructions of the page not to cache or store it, so every reload requires another request to the web server.
This is a big problem for me. I do a lot of online editing and often have to look back several pages to get some code/css I deleted on a previous page that didn't think I needed any longer or to fix a mistake that didn't crop up until several saves later. IE behaved this way which is a major reason I switched to firefox long ago.
Looking at my headers there is no expiration date set so firefox isn't exactly *honoring* any instructions, it's simply not caching by default even though I have firefox set to use the cache
We've implemented all the "anticache" instructions where we need them, the new firefox model is the inverse of what we actually need. PLEASE PLEASE cache by default like you used to or at least make this new behavior optional. I've lost several hours of work/code and css because of this new model.
Here's an example of my headers and as you'll see those no expiration instructions: http://mydomain/cgi-bin/mypage.cgi POST /cgi-bin/page.cgi HTTP/1.1 Host: www.mydomain.com User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://www.mydomain.com/cgi-bin/mypage.cgi Cookie: __utma= Authorization: Basic xxxxxx== Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 6644 do=page&content=THEPOSTEDCONTENT HTTP/1.1 200 OK Date: Thu, 18 Sep 2014 17:44:45 GMT Server: Apache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 4743 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1
Hi klangan, did you notice this issue starting with Firefox 32?
A user who has been investigating this in detail reports that when the cache is full Firefox will start displaying the Document Expired page, suggesting that Firefox's caching behavior has changed in Firefox 32. Related thread: Firefox 32 always gives "Document expired" every single time I hit the Back key to return to search results.
선택된 해결법
Yes, Firefox 32 is when this behavior began.
I just went in and checked Tools->Options->Override Automatic Cache Management and for the moment at least, the problem has disappeared.
Thanks, hope this solves the problem.