Closed Bug 89094 Opened 24 years ago Closed 24 years ago

When the history for the back button fills up with the same name it is not possible to go back

Categories

(Core :: DOM: Navigation, defect)

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: alciocca, Assigned: radha)

References

(
URL
)

Details

If you go to a site like metalink.oracle.com and enter a query, look at the results, use back to enter another query and do this often enough that the back history is full with the same name it is no longer possible to go back. For example at this site (sorry you have to register to use it but I'm sure there are others like it) the history fills up with Metalink 2 for the length of the list below the back button. From that point on you can't go back. Sorry I just realised I said the same thing twice! Just wanted to make it clear...
->Component: Session History
Assignee: asa → radha
Component: Browser-General → History: Session
QA Contact: doronr → claudius
I've got the same problem with zope development. Before reading this bug i did not find any thing to reproduce the bug but the desciptions sounds reasonable to me. IMO the severity should be raised at least to critical.
Actually I have now noticed that this can also happen even when the history is not full of the same thing. It must have something to do with there being more one item with exactly the same description in the history next to each other.
Could be. Don't know. Occours mainly (only?) in form-post/frame context i think.
I think I've seen this on www.mozillazine.org a few times. When clicking Back, it actually jumped back more than one history items. Mozillazine also stuffs your history full of items with the same name now and then, however, I tested it and I couldn't reproduce it anymore by filling the history with items with the same name. I'll play around with it some more. It looks like it's indeed related to form posts.
I had this now with no form posting but only frames. Frames cause mozilla to fill up the history with the same items, too. Hmm.. this bug is really hard to track down... but it is a nasty one.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes it is definitely frames related.
I would like a good test case. Registering at the above site needs a support identifier, which I do not have. I recently fixed a bug with sequentially repetitive frameset pages. Is this bug appearing in latest builds?
little help? reporter, could you try again with a recent build? can anyone repro(somewhat reliably) elsewhere?
Keywords: qawanted
I have tried with most builds, I just tried now with Mozilla 0.9.3+ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010904 but it still exibits the same behaviour. I have seen it on other sites with frames as well and when I can find one again I will post it.
OK, I found a site where this problem occurs every time and you don't even have to register! http://www.jobnet.com.au/ go to job browse, try a location with a lot of jobs, like sydney jobs, then click on a job description, click back, click on a job description, click on back, etc. it took me 8 job descriptions to reproduce the problem....
thanks for tracking down a testable site adam. Radha, after learning all about australian jobs for 1/2 an hour this is all I found which may be a different bug: Clicking the job browse,sydney jobs, or any job description link puts the same title info into SH (the 'Go' menu and the back dropdown menu). using the dropdown menu on the back button to return to the first (home)page (http://www.jobnet.com.au/) results in the forward button not lighting up. to repro: 1. go to http://www.jobnet.com.au/2. click 2nd link on LHS navpanel "Job Browse" 3. Use the drop down menu on the back button to select the first page. 4. notice the forward button is no longer active like it should be. I can make an new bug if need be. I can't repro the reporter's exact problem - the back button always worked. 20010904099 builds
URL: http://metalink.oracle.com → www.jobnet.com.au/
This bug is fixed now. I checked in some changes last week, in this area for another bug. I can't reproduce the bug with the url mentioned here.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I don't know about fixed, I can still reproduce it with a new build (2001100721), same url, same result...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Adam, what can you reproduce? With a 2001100815 linux trunk build I can't reproduce any misbehavior - not whatever the original bug was supposed to be and not the issue I later outlined (previously in this bug).
I can reproduce it on latest windows build (2001101103). I was using method described by Adam, and managed to reproduce the problem on second job description. I'm using windows 2000.
Hi Claudius, I can reproduce not being able to go back. I will try with a new profile maybe there is something there as this problem is 100% reproducable for me so it seems strange that you can't. Also a lot of other people seem to have the same problem on all sorts of platforms...
OK, fresh build and a new profile and I can't go back after looking at two job descriptions...
I spent quite some time in this site going thro' differnt job descriptions, following Adam's steps and Claudius's steps. I can't reproduce anyof the problems in today's trunk build.
I really can't explain it, is it something with my OS? I will try on windows when I get a chance but I just tried the latest trunk (2001101808) and it won't go back after one job!
I'm seeing this in Win2k. I believe I have found a key step to reproduce this bug. Click a link. Immediately after the the barbar pole effect goes away, and you get a real progress bar, but before the page actually changes, hit back. BAM! There went the back and forward buttons' ability to do anything. If you look in the go menu, you'll notice that the latest entry is checked, as if the navigation thinks you are there, although the browser is displaying the second to most recent entry. Selecting the second from most recent entry won't do anything since you're already there. Selecting the most recent entry goes there, as well as any other than second from last, since you aren't at that site. This makes it pretty clear why the back and forward buttons are malfunctioning. The history thinks it's already at the end (last entry), so when you click the forward button, there's nowhere for it to go. In fact, you can verify this if you did it in such a way to make the forward button still enabled. If you click the down arrow to bring up the pop-up menu for the forward button, you'll get a tiny empty menu. When you click the back button, it goes to the history as well, and also mistakenly believes you are at the last history entry, just like the back button, but this time it does have somewhere to go. Of course that location is where you are already browsed to, so nothing happens. It looks to me like the buttons are working fine, but the session history is screwing up and giving the wrong info about position in the history. This only occurs on certain sites... The following forum causes the problem: http://www.ddrfreak.com/forums/UltraBoard.cgi And it is a good testcase since it doesn't use frames.
The latest description looks very similar to bug 103978. I have attached a patch there, that has fixed similar problems at cnn.com. I tried the patch on the latest site mentioned by burpmaster and I couldn't reproduce it. A independant verification can help me resolve this bug appropriately.
Target Milestone: --- → mozilla0.9.7
Hmmm, I'm looking at 20011025 builds on mac and Linux and following burpmaster's recent steps I am unable to repro this bug (still) Radha, did you already checkin that patch? Can anyone else still repro (at www.ddrfreak.com)?
I can't reproduce this anymore. I think it's fixed.
It is fixed in the latest nightlies. Using a build from the 25th I can't reproduce the problem. Brilliant!
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.