Closed Bug 93445 Opened 24 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: