Closed Bug 30030 Opened 25 years ago Closed 24 years ago

Infinite loop if back button pressed leads to JS redirect

Categories

(Core :: DOM: Navigation, defect, P3)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: radha)

References

Details

(Whiteboard: need help to verify)

Step to reproduce:

1) Go to the URL http://www.camtechsystems.com.

2) Let the redirect happen (you will go to the "Old Browser" page).

3) Press 'Back'

4) When the "Old Browser" page loads again, press 'Back'

5) Continue this until Mozilla enters an infinite loop of reloads (it usually 
only takes twice or three times).

Occurs with M14 final and debug and opt builds pulled from CVS this morning at 
8:30.
The JS code is executing fine each time the page is loaded. There's no script on 
the target page so I don't know why it's immediately going back again after the 
first couple of times.

cc'ing radha since I don't know where this goes, sorry.
Assignee: rogerl → gagan
Component: Javascript Engine → Networking
QA Contact: rginda → tever
Sounds like one for Radha.
Assignee: gagan → radha
Status: NEW → ASSIGNED
Component: Networking → History
Looks conceptually similar to bug 20283, "Infinite loop when anchor has 
javascript:history.go(0)"
bug 20283 has a lot to it. I think maybe radha should take a look and decide whether she wants to dupe it or not.
Well, the JavaScript history does not seem to be 0 here, and it is not in an 
anchor. But, if it is a dup then mark it. You guys know more than me ;-)
Target Milestone: M16
Keywords: nsbeta2
Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.
QA Contact: tever → claudius
Whiteboard: [nsbeta2+][6/01]
I can no longer reproduce this because the page has changed (no redirect) does anyone have (or can suggest) an independent 
testcase?
Move to M19.
Target Milestone: M16 → M19
Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.
Whiteboard: [nsbeta2+][6/01] → [nsbeta2+][Will be minus on 6/15]
Has anyone seen this recently or know of a testcase? I'd like to argue for this bug to be nsbeta2+(no date) but w/o a reproducible 
testcase my argument would have no merit (and rightly so).
I belive the problem is still there. However, I dunno of a test case. 
Well, I tried to make a testcase, but since there are some other bugs in JS now, 
I cannot. Specifically, redirect pages that use document.location are not placed 
in the history. Oddly enough, pages that use location.replace() remain in the 
history.
Cleaning up status whiteboard marking beta2 minus (we're past 6/15)
Note that the discussion suggests that there is no longer a test case to be 
had... and perhaps this should be just marked "fixed" until/unless there is a 
current example.
Whiteboard: [nsbeta2+][Will be minus on 6/15] → [nsbeta2-]
Ummm. There can't be a testcase until someone fixes the JavaScript history bugs 
that exist. These bugs are blocking any testing on this.
Nav triage team: [nsbeta3-]; marking dependency on 18321
Depends on: 18321
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
*** Bug 33311 has been marked as a duplicate of this bug. ***
Depends on: 30942
I don't see any redirection to teh old page in the above url. Please provide a 
good url
Bug 42723 is preventing me from testing this (read second comment about location 
= foo.bar acting like location.replace)
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3
42723 is fixed. Most of the JS hookup with SH is done. Marking this fixed. 
Reopen if the problem still exists.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I need a hand here. If someone can accurately verify this fix please do. If someone can create
a JS testcase that demonstrates the fix - even better.
Keywords: qawanted, verifyme
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-] need help to verify
Keywords: nsbeta2, nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-] need help to verify → need help to verify
No longer depends on: 30942
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Depends on: 368603
No longer depends on: 368603
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.