Closed Bug 93445 Opened 23 years ago Closed 23 years ago

BACK button stops responding after a few 'fwd-back' clicks

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: shrir, Assigned: radha)

References

(
URL
)

Details

Attachments

(1 file)

Shows div.innerHTML w/iframe back button bug
387 bytes, text/html
Details
win NT 0802 trunk, recently filed another bug on similar lines...it was a crasher though, here the back button just stops responding steps: 1 go to cnn.com page 2 On the right, under 'Top Stories' , click on the 'Genesis launch scrubbed again' link (http://www.cnn.com/2001/TECH/space/08/03/genesis.update/index.html) 3 Now, after the page loads, quickly click on BACK and FWD buttons 4 Once the page contents are visible again, click the BACK buton once.. Result: Observe that nothing happens. No page loads even though the history list is not empty.
*** Bug 93629 has been marked as a duplicate of this bug. ***
*** Bug 94710 has been marked as a duplicate of this bug. ***
steps/testcases from duped bugs: I : http://www.geocities.com/SiliconValley/Heights/2884/ Steps to Reproduce: 1. Load any page with frmae 2. Browse the page (using links that navigate within the frames (for example a Table of Contents navigating pages in another frame. 3. Press the back button. The first couple of times it will work. Then it stops working and the back button does nothing. II : http://www.bvd-ticket.de/ Steps To Reproduce 1.open URL 2.select link "Veranstaltungen" (left, red underlined) 3.in content frame choose link "Bizarre Festival" (or any other) 4. click on link "ZURÜCK" (== history.back()) or try other methods to go back
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Hi, I'm seeing the similar problem on the following japanese page, http://www5b.biglobe.ne.jp/~tototo/peg/a/aa/newpage1.htm I select all check box and click the button on the page, the next page uses history.back() but I click the button on the page, nothing happens. Is this the same problem?
*** Bug 95999 has been marked as a duplicate of this bug. ***
Severity: normal → major
The bug also occures on linux (and was set to "duplicate" of this bug), and I will give here an other example because I was not able to reproduce the other *.de-example presented here: Steps to Reproduce: 1. Go to http://autsch.rtl.de/frames.html 2. Click "Weltschmerz" on the left side (other do also) 3. Choose "High Soxx" in the middle 4. Scroll down, click on one of the red links in the middle 5. Try back-button. If it works - retry with other red link. More than 80% does not work 6. If "Back" does not work, try the second line in "multi back", it brings you back
I could not reproduce any of these problems in a latest build. I have fixed some bugs with frameset pages lately. Please verify. marking WFM.
Actually marking WFM
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
nope..i can still clearly reproduce the problem. Let me know if you want me to show it to you. reopening. steps: 1 go to cnn.com 2 under 'Top Stories', click on 'Feds Drop Microsoft breakup' 3 Now, after the page loads, quickly click on BACK and FWD buttons 4 Once the page contents are visible again, click the BACK buton once..
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Is the problem primarily reproducible if the back-fwd buttons are pressed quickly before the pages are completely loaded? If so, I think it is a different problem. Most of the other testcases in this bug are about loading a frameset page, navigating inside it and going back and forward there.
yes..but this is one of the guaranteed ways to repro the problem. I have also noticed this on newsgroups while I am within threads (not clicking buttons rapidly). I will try to get a scenario there.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.5 → mozilla1.0
Still happening regularly at http://www.cnn.com with build 2001102602. No need to switch pages while they're still loading. I browse CNN every day, so my guess is it happened after the 0.93 build.
Getting this bug on this page as well. Stepping backwards and forwards, looking at history-related bugs, I'm getting the error (Win98, Build: 2001102708)
Bug 103978 which was fixed on friday 10/26 could have fixed this one. Can some one try today's build and update?
Looks fixed on Win98, build 2001102903 (last night).
It still happens to me on occasion, but I haven't been able to come up with a consistent way to reproduce it (and when I tried some of the steps outlined by others here they didn't trigger the bug for me now). It seems like, when the back button stops working like this, the history as shown in the Go menu always has a lot of repetitions of the same title in it, which may be the way Mozilla shows it when you navigate within a frameset.
shrir, Can you try to reproduce this bug in latest builds. I not reproducible anymore, I would like to close it out. Thanks,
Unless Harry Potter or some developer works on this bug, it's not going to get fixed. ;).. This still happens ( my NT is blocked due to bsome installer crasher)
I'm getting a funny related bug with some HTTPS sites, when they have a redirect to the HTTP version instead, doing a "back" sends you to the HTTPS (which is blank) rather than the HTTP version which had content. I'd give an example, but I doubt that most ppl here can get into the secure pages of the Computer Science department of the University of Bristol.... anyone else seeing this somewhere more public?
This attachment reliably reproduces a bug in the browsing history (back and forward buttons). It seems to be related to the other problems noted here. To see the bug in action, do the following: 1) Navigate to any page (other than the attached). 2) Navigate to a saved copy of the attached file. 3) Click the button. 4) Try to click the back button in the browser (or use the context menu). Nothing happens. The back/forward functions are totally clobbered after this.
Keywords: nsbeta1
Radha, any chance of bumping this up now that there's a reproducible testcase? There seem to be lots of ways to kill the back button, it can't hurt to fix this one. Many 6.2.1 users reported encountering this.
as reporter of this bug: this still happens, true.
plusing - ADT/Embedding triage team.
Keywords: nsbeta1 → nsbeta1+
well...I can't reproduce this bug (initial problem) anymore. I tried a lot to make it happen..but things just work fine now. Radha, feel free to change this one to whatever u please...close it/resummarize for the new problem mentioned at the bottom...
I still get this problem all the time. It has not changed behavior in the last several revisions, and it still exists in the latest one.
Running 0.9.8 on Win2k (build 2002020406), on Solaris (2002020516), and on RH Linux 7.2 (build 2002020415). I have not been able to duplicate the problem with these builds. Please feel free to do whatever you think is best.
CM: Can you debrief me on what it is that you are able to reproduce? The original problem reported here or your test case?. The testcase that you have provided is totally a different problem from what was originally reported here. The testcase bug still exists and I'm trying to figure if it needs a separate bug and warrants a nsbeta1 nomination. This bug is turning out to be a place holder for various types of back/forward bugs. I would like clear it up and make sure that the right problem gets the right nomination.
I'm referring specifically to the general flakiness of the back/forward buttons. Every once in a while, they'll just stop working for a particular browsing window. I honestly wish I had more details than that :( Perhaps I am just smoking something :) C
I have the same problem. I'll be browsing and both the back and forward buttons will just randomly grey out, and then never come back on. It is very annoying and causes me to use IE quite often. I have the problem quite often on windows 98, but I don't recall ever seeing it in Linux.
Since the original problem is not reproducibel anymore, I'm going to mark this WFM and create a new bug for the IFRAME problem along with its testcase. I also can not reproduce the problem with http://www.bvd-ticket.de/ http://autsch.rtl.de/frames.html http://www5b.biglobe.ne.jp/~tototo/peg/a/aa/newpage1.htm
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: