134028 - javascript href to target in frame continuously loads page.

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[d robertson]

On a 2 frame frameset, one frame executes a javascript on the body onLoad event
to href to a target within that page.  This is used to auto scroll down to a
particular place within the page upon loading.  The frame with the
javascript/target will continuously access the page from the server, forever,
and never stop and display that page.  Strangly, this doesnot happen on a single
page (without the frameset); you can access the problem page directly with no
problem.  I have a demo page here:

http://www.drobertson.com/mozilla/mztest.html

Access the url and the bottom frame will not load and stop; it is continuously
accessing the webserver for the page (access logs show this).  The bottom frame
has the onLoad javascript function, and the target.  The top frame is only there
for demo purposes.  

You can hit the STOP button and the page will display properly.  RELOAD button
will cause the problem to startup again.  SHIFT-RELOAD will NOT cause the
problem, and the page will load once and display properly.


There is some commented-out alerts in the js function tha can be used to further
demonstrate the problem.  But if you use them, you will have to end-task mozilla
because it is calling the js function repeatedly, and the alert will show again
as soon as you close it, forever.


It appears that the onload event is called, the js function does an href to a
target inside the page, but mozilla thinks it is an href to an external page,
and calls the server for it (the same page), upon where it repeats the scenario
again.... 


If you access the bottom frame page directly, the problem does not occur (thus
it is frame related):

http://www.drobertson.com/mozilla/mztestbody.html


My cache is set to when the page is out of date.

This problem did not exist in milestone 9.8, but does in 9.9, and in this
nightly.  Tested only on win nt 4.0.

Comment 1

[benc]

+testcase
-> browser-general
no contributor comments after two weeks.

Is this a js bug? I have limited expertise here, and was unable to figure out
what is going on.

Comment 2

[d robertson]

I cant say for sure what is causing the bug; wherever in code that controls how
a redirect to a target on the current page within a frame, is processed.  The
bug does not happen on a single page (without a frameset).  


This example includes a frameset consisting of 2 frames.  Ignore the top frame,
it is only there to create a frameset.  The bottom frame contains a simple
javascript redirect to a target within the page (important- the target is
located on the current page, not another url), that is run on the page onload
event.  The browser should just load the page and scroll down to the target
located on that page.  But instead, the browser goes back to the webserver and
gets the page again, loads it, the onload javascript runs again, and this
process continues forever.   It seems that the browser thinks the redirect is to
another page and not merely a target located on the current page.  It appears to
the user that the browser is not loading the page, but what it is really doing
is continously reloading it from the webserver.  

Note that it takes a frameset to create the problem.  Note also that hitting the
reload button causes the problem to occur, but hitting shift-reload does not
cause the problem (page loads and scrolls down to the target as it should). 

Comment 3

[Boris Zbarsky [:bzbarsky]]

To DOM0.  We're loading the URI instead of scrolling here....

Comment 4

[Boris Zbarsky [:bzbarsky]]

dom0 for real

Comment 5

[d robertson]

Noticed that this bug has not been addressed yet.  Should the severity be
raised?  Although the likelihood of encountering this bug on the web is somewhat
remote, the effects of it are drastic- not only does it appear to put the
browser in a loop, it uses up a webserver thread and fills up the server logs
with its continuous page access.

Comment 6

[d robertson]

This bug could probably be marked as resolved, as it appears to be fixed now in
1.3 beta:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

Comment 7

[Boris Zbarsky [:bzbarsky]]

So it is.  ;)  Marking worksforme per comment #6 and my testing with linux trunk
build 2003-02-07-08.