Closed Bug 124245 Opened 23 years ago Closed 22 years ago

javascript onload redirect breaks back button

Categories

(Core :: DOM: Navigation, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: aufbau01, Assigned: radha)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file)

Patch to docshell
(deleted), patch
rpotts
: review+
alecf
: superreview+
roc
: approval+
Details | Diff | Splinter Review
Steps to reproduce: 1. Go to http://cgi.netscape.com/cgi-bin/upgrade.cgi. (Optional) 2. Click the link to http://cgi.netscape.com/cgi-bin/nsda_check.cgi from this bug report or from upgrade.cgi. Actual result: Redirected to 404 page. Hitting "back" doesn't work. Expected result: Hitting "back" should work. I'm using a build from today, 2002020703.
On Linux too. Clicking back twice works well. Clicking back once just hits the redirect again. Probably we should go two pages back on redirects if they are faster than 1 second. I'd even prefer to stay on the redirecting page.
OS: Windows 98 → All
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Session history does support redirects caused by <Meta http-equiv ...> headers. The redirecting page will not be stored in session history in such cases. It appears that this page is not using it.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
"Session history does support redirects caused by <Meta http-equiv ...> headers. The redirecting page will not be stored in session history in such cases." Why? Netscape 3 & 4 do. Why should any page ever be excluded from history?
mrmazda: http://www.top9.com/lockin.html. Sites using fast redirects used to inadvertently prevent their visitors from leaving the site using the Back button. Instead of continuing to complain to (or about) those sites, Mozilla fixed the problem in the browser. This bug represents one case that Mozilla didn't fix.
"Sites using fast redirects used to inadvertently prevent their visitors from leaving the site using the Back button." I thought it was webmasters fulling intending to trap visitors with virtually instant redirects that effectively break the back button. What other point is there to a redirect in three seconds or less? "Instead of continuing to complain to (or about) those sites, Mozilla fixed the problem in the browser. This bug represents one case that Mozilla didn't fix." Mozilla simply replaced one problem with another problem. When the redirect is not fast, the page should not be omitted from history.
when the redirect is not fast, the page is not omitted from history. The page is stored in history. Mozilla uses a threshold of 15 seconds to decide if a page should stay in history or not. If a site uses <meta http-equiv ..> and redirects to another site with in 15 seconds OR redirects to another page in onLoadHandler() etc ..., the redirected page will replace (and thereby eliminating) the redirecting page from history. If the redirection happens after 15 seconds, the redirecting page stays in history. One may argue about the time limit. But this is just something we thought was a reasonable number. I know that Netscape 3 & 4 don't behave this way. They keep the redirecting page in history and makes you get trapped. I have found (through bugs) that it is not a good idea to follow Netscpae 3 & 4 behavior in this case. Marking this bug Won't fix, since I don't intend to change the current behavior w.r.t. redirected pages. BTW, The url http://cgi.netscape.com/cgi-bin/nsda_check.cgi is not available anymore.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Please reconsider changing behavior slightly. 15 seconds can be too long a threshold. If a page does provide useful information, but all of it can be read in 6-10 seconds, then 15 seconds is much too long a threshhold. Shutting immediate redirects (0-5 seconds) out of the history should be sufficient. Where did the 15 seconds come from?
Radha: I know http://cgi.netscape.com/cgi-bin/nsda_check.cgi doesn't exist. In my original bug report, I said that it redirects you to a 404 page. This redirect happens in under five seconds, yet hitting back does not return to this bug report.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I see what's going on here. I can't sneak it in for Mozilla 1.0.1. Moving to Mozila 1.1 beta
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla1.1beta
resummarising.
Summary: Can't go back after redirect(s?) → Back button misbehavios on pages redirected to a 404 error page.
If you click the link from http://www.haaretzdaily.com/hasen/pages/ShArt.jhtml?itemNo=178487 to http://www.haaretzdaily.com/hasen/objects/misc/BackHome.jhtml, you also get an onload redirect and can't use the back button. This is the entire HTML of BackHome.jhtml: <body onload='location.href="http://www.haaretzdaily.com/"'></body> I used putty (telnet) to verify http://cgi.netscape.com/cgi-bin/nsda_check.cgi also uses an onload redirect. Other bugs related to setting location.href in onload: bug 151617 set location.href in onload -> throbber forgets to animate bug 155313 location='javascript:' in onload delays painting for a second
URL: http://cgi.netscape.com/cgi-bin/upgra... → http://cgi.netscape.com/cgi-bin/nsda_...
Summary: Back button misbehavios on pages redirected to a 404 error page. → javascript onload redirect breaks back button
Attached patch Patch to docshell (deleted) — — Splinter Review
The patch takes care of loads triggered by onload handlers on root dochshell. We already take care of similar situations for subframes.
Comment on attachment 90996 [details] [diff] [review] Patch to docshell sr=alecf
Attachment #90996 - Flags: superreview+
Comment on attachment 90996 [details] [diff] [review] Patch to docshell r=rpotts@netscape.com
Attachment #90996 - Flags: review+
Comment on attachment 90996 [details] [diff] [review] Patch to docshell also r=mcafee
Comment on attachment 90996 [details] [diff] [review] Patch to docshell a=roc+moz for TRUNK
Attachment #90996 - Flags: approval+
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Blocks: backtraps
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: