124245 - javascript onload redirect breaks back button

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Niels Aufbau]

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.

Comment 1

[Arthur]

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.

Comment 2

[Radha on family leave (not reading bugmail)]

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. 

Comment 3

[Felix Miata]

"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?

Comment 4

[Niels Aufbau]

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.

Comment 5

[Felix Miata]

"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.

Comment 6

[Radha on family leave (not reading bugmail)]

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. 

Comment 7

[Felix Miata]

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?

Comment 8

[Niels Aufbau]

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.

Comment 9

[Radha on family leave (not reading bugmail)]

I see what's going on here. I can't sneak it in for Mozilla 1.0.1. Moving to
Mozila 1.1 beta

Comment 10

[Radha on family leave (not reading bugmail)]

resummarising.

Comment 11

[Jesse Ruderman]

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

Comment 12

[Radha on family leave (not reading bugmail)]

Attachment: Patch to docshell

The patch takes care of loads triggered by onload handlers on root dochshell.
We already take care of similar situations for subframes.

Comment 13

[Alec Flett]

Comment on attachment 90996 [details] [diff] [review]
Patch to docshell

sr=alecf

Comment 14

[rpotts (gone)]

Comment on attachment 90996 [details] [diff] [review]
Patch to docshell

r=[e-mail]

Comment 15

[Chris McAfee]

Comment on attachment 90996 [details] [diff] [review]
Patch to docshell

also r=mcafee

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 90996 [details] [diff] [review]
Patch to docshell

a=roc+moz for TRUNK

Comment 17

[Radha on family leave (not reading bugmail)]

Fix checked into the trunk.