User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060113 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060113 Firefox/1.6a1 Unfortunately can't reproduce it, but the back button and Back in the context menu sometimes stop working. I believe it's like this at least a week in the trunk. Reproducible: Sometimes Steps to Reproduce:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060113 Firefox/1.6a1 ID:2006011323 WFM. Does the Back button not respond or do you see an attempt to go back that just not succeeds?
Back button does not respond. It is caused by forms, but only intermittently.
Component: General → History
Don't know if this is the same problem, but it might be. I think there is a problem with SessionSaver and trunk, where it doesn't let you go back if the previous page contained postdata. Steps to reproduce: 1. Make sure SessionSaver is installed. 2. Go to http://www.bestbuy.com/site/olspage.jsp?type=category&id=pcmcat33200050001 3. In the select dropdown choose "Sort by Price". 4. Click on one of the hard drives shown, then try to go back using any form of back (context menu, button, mouse button, etc.). Nothing happens. It's like the buttons weren't pressed.
OS: Windows XP → All
QA Contact: general → history
Hardware: PC → All
*** Bug 323419 has been marked as a duplicate of this bug. ***
I do have session saver, and I have it disabled (not to restore automatically on start-up). This is making some sites completely unusable with Firefox. I cannot browse the photo galleries at photo.net, for instance.
Happens also in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060118 SeaMonkey/1.5a So far I'm always getting this after submitting some form which displays a short intermediate page and then redirects to the real page with meta refresh tag, like most vBulletin forms do ("Thank you for ... You are now being redirected to ...").
I have removed SessionSaver and still experience this problem on nearly every site that is form-driven.
Safe mode works so far. The extensions I have do not seem like they would interfere: Pop-ups Must Die Live HTTP Headers Down Them All Add N Edit Cookies Adblock
I have no extensions except for Live HTTP Headers.
I can reproduce this 100% by submitting a comment to Slashdot and trying to go back after submitting the comment.
Removing LiveHTTP Headers fixes the problem.
Verifying that this ONLY seems to occur if Live HTTP Headers extension is enabled. The broswer does not go back a page and the dialog box about Postdata never appears either. I will try to narrow down a regression window because I am sure this worked at some point with the exact same version of Live HTTP Headers.
I have narrowed this down to it working with the 2005123005 WIN32 trunk build and failing with the 2006010315 WIN32 trunk build. I cannot find any builds between those 2 builds.
I also filed mozdev bug# 13095 against livehttpheaders on this issue.
Assignee: nobody → darin
Component: History → Networking
Product: Firefox → Core
QA Contact: history → benc
This appears to be a regression from the checkin for bug 318193. Althaough normally I would assume an issue related to an extension woudl be the extensions fault, looking at the extension code I don't see anything obvious that should be causing the back button in the bowser to fail to function.
OK, I will investigate this bug.
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.9alpha
13 years ago
Summary: Back button sometimes doesn't work → Back button sometimes doesn't work when using Live HTTP Headers
12 years ago
I'm pretty sure this only happens with POST requests.
Summary: Back button sometimes doesn't work when using Live HTTP Headers → Back button doesn't work when using Live HTTP Headers if the page was the result of a POST
It just happened to me with Live HTTP Headers disabled. I have no idea how to reproduce.
Does this 'broken back button' also include the backspace key and the Alt-left keys not working? Those combinations are 'back button' keyboard equivalents. (Consider this next bit anecdotal, not confirmatory. I think I may have had this happen to me once where the backspace key didn't go back a page. Alternatively, I may have not hit the key hard enough or the keyboard flaked out that time. I can't confirm a pattern yet.)
(In reply to comment #21) > Does this 'broken back button' also include the backspace key and the Alt-left > keys not working? Those combinations are 'back button' keyboard equivalents. I think so. It just happened on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060729 Minefield/3.0a1 ID:2006072918 with LiveHTTPHeaders version 0.12 (the max version altered to 3.0+)
my guess is that this is related to livehttpheaders closing the stream as debugged in bug 336501. Note bug 336501 comment 20. until that's fixed I would claim this is a livehttpheaders bug.
This bug is very strange. I just installed Live HTTP Headers to see if I could find out why this happened, but it seens that NOTHING happens in Live HTTP Headers when I have the bug. It's hard to reproduce too, I have it often on www.eksperten.dk though... To recap, it has nothing to do with Live HTTP Headers - I only installed it to see if that would reveal anything about the bug. My symptoms: I press back (or BKSPC) and the browser hangs indefinitely (statusbar says "Waiting for www.eksperten.dk..." for instance. Then, 10-200 seconds later the page loads. New tabs, stopping it and clicking on other links on the page, has no effect; it doesn't work until later. Very weird.
Lars Petersen: I suspect that's a different bug... this bug, as I understand it, is about the case when back is not just slow but doesn't work at all.
> Does this 'broken back button' also include the backspace key and the Alt-left > keys not working? Those combinations are 'back button' keyboard equivalents. > > (Consider this next bit anecdotal, not confirmatory. I think I may have had > this happen to me once where the backspace key didn't go back a page. > Alternatively, I may have not hit the key hard enough or the keyboard flaked > out that time. I can't confirm a pattern yet.) I've noticed this a great deal. Many sites that rely on HTTP POST seem to lose the session Back history for that window when you follow a link. Very frustrating.
-> reassign to default owner
Assignee: darin.moz → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.