Throbber does not stop when inner frame sets img src or iframe src via JS




Layout: HTML Frames
16 years ago
10 years ago


(Reporter: Aitor, Assigned: John Keiser (jkeiser))



Windows 2000
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(5 attachments)



16 years ago
With a frameset embedded within another frameset, if the onload method of the 
embedded frameset attempts to change the location of one of its frames, the 
browser doesn't stop loading the page. This bug doesn't allow to store the page 
at the back button history.

Comment 1

16 years ago
Browser, not engine ---> HTML Frames
Assignee: rogerl → jkeiser
Component: JavaScript Engine → HTMLFrames
QA Contact: pschwartau → amar

Comment 2

16 years ago
Created attachment 85200 [details]
Various html files that demonstrate Frameset/Onload bug

After un-zip, run FramesetTop. This will open a trace window. Note two things,
one: the page loading indicator for this page never stops loading (the trace
window never stops loading, but that is done on purpose), two: the trace for
FramesetTop never is processed.

This is caused by using replace() in the middle frameset. To verify: go to
FramesetMiddle and comment out this line:

Run again, and you will see that it all behaves correctly. In this example the
new page (page12.htm) is simple. In the actual application the page(asp) is set
with a number of parameters which could not easily be done any other way.

The actual application is a health entry system for the state of Washington. We
are finishing it up and attempting to get it to work under Netscape
6.2/Mozilla. For us, this is a biggie.

Thank you,

Chris Emerson

Comment 3

16 years ago
This doc should have been part of the html files uploaded by Emerson. 

This doc merges the middle frameset and the top frameset. Each one has an onload
action. Note that when this is run only the lower level onload action occurs.
The onload event for the first frameset does not fire. (This is the same
behaviour seen in IE).

This implies one possible reason for this bug: the browser "sees" all of the
framesets as combined. In this case once it processed the lower level onload it
ignores any higher level onloads. Since the pages all load (the loading
indicator clears) this maybe a different issue.

Chris Emerson

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<title>Frameset: top</title>
<script language=javascript src="test.js"></script>

<script type="text/javascript">
function loadPage ()
   Trace("** ONLOAD: FramesetMiddle");
   var url;
   url = "page12.htm"
   Trace("--replace page3 with page12--");
// -->

<frameset rows="100,*" onload="Trace('** ONLOAD: FramesetTopCombined');">
<frame src="page1.htm">
   <frameset rows="100,*" onload="loadPage();">
   <frame name = "middle01" src="page11.htm">
   <frame name = "middle02" src="page3.htm">

Comment 4

16 years ago
Created attachment 85267 [details]
Testcase innerframe

Comment 5

16 years ago
Created attachment 85270 [details]

This happens when the outer frame is an iframe as well.  The problem is that
whenever you have a document-within-a-document and the inner one changes its
location during load, the loading throbber does not stop even though loading
has.  This is not a problem with frameset-within-frameset; as was just pointed
out, if you put them in the same document everything works.  The DocShell
boundary is the thing.

You can test the behavior it *should* have by clicking on "Testcase
innerframe".  Since there is no outer document, the frame is replaced and the
throbber stops.  But clicking on "Testcase", which has an iframe pointing to
"Testcase innerframe", fails the test.

One strange (but probably unrelated) thing is that the inner frameset does not
receive an onLoad event when the location of the inner frame is replaced.  This
occurs, for example, when an iframe.src is set, making onLoad='this.src="..."'
a recursive event.

Is this causing functional problems with your application or is it just the
throbber?  (I understand that's a real problem, just wondering if this is
having any deleterious effects on you data-wise.)

Comment 6

16 years ago
The functional problem is that it doesn't stop loading, and no pages are stored 
as part of the history array. So no back button is working (Neither browser's 
back button nor history.back() )

Comment 7

15 years ago
Could bug 139769 be related to this? If so, it's a problem -- it shows a
big-time memory leak on the current builds. If not, well, maybe not. :-)


15 years ago
Blocks: 152057


15 years ago
Ever confirmed: true

Comment 8

15 years ago
*** Bug 153566 has been marked as a duplicate of this bug. ***

Comment 9

15 years ago
*** Bug 151600 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
*** Bug 152057 has been marked as a duplicate of this bug. ***

Comment 11

15 years ago
Created attachment 91397 [details]
onload within frameset does not display message in Netscape Navigator 6.2.3

Please add any two pages as Page1.htm and Page2.htm. MainPage.html displays
alert message in Netscape Navigator 4.7 and IE 5.5. But it does not display the
message in Netscape Navigator 6.2.3.

Any workaround?

Comment 12

15 years ago
I can confirm the behavior reported by Comment #3 From Christopher Emerson.
In its example the onload-handler of the outer frameset will not
be invoked (this is also with InternetExplorer). But i could not reproduce
the endless loading problem. Thus i have made another test with
frames and onload-handler. The components are:

An outer frameset fs1.html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<script type="text/javascript">
function init () {
alert("fs1:frameset:loading done!");
// -->
<frameset rows="*,*" onload="init();">
<frame src="page1.html">
<frame src="fs2.html">

An inner frameset fs2.html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<script type="text/javascript">
function loadPage (){
var url;
url = "page3.html"
alert("replace page2 with page 3!");
function init () {
alert("fs2:frameset:loading done!");
// -->

<frameset rows="*" onload="loadPage();init();">
<frame src="page2.html" name="fs2_doc">

And page1-4.html like:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
page 1

If you load the URL
the onload-handler of the inner frameset fs2.html will be invoked
and the page2 is replaced with page3 and the the handler is
finished. The onload-handler of the outer frameset will not be
invoked and Mozilla is loading endless. If you want to get the sources,
just use . My testing environment
is Win2000/Mozilla1.0.1. This expample works fine with InternetExplorer!

Comment 13

15 years ago
*** Bug 165962 has been marked as a duplicate of this bug. ***

Comment 14

15 years ago
OK.  This also happens when the inner doc is a normal document that contains an
image, and the image's src gets set.  The general problem is that the outer
document gets confused about whether it's done loading if JavaScript loads
resources in the inner document while loading.
Summary: Frameset and onload → Throbber does not stop when inner frame sets img src or iframe src via JS


15 years ago


15 years ago
Keywords: testcase
Priority: -- → P3


15 years ago
Target Milestone: --- → Future

Comment 15

14 years ago
Below is the testcase from bug 166328, which now bug 217000 has been fixed,
seems to be displaying this problem. Yes?

<head><title>Testcase for bug 166328</title><meta http-equiv=Content-Type
content=text/html; charset=UTF-8></head>
<SCRIPT language=JavaScript>
function output_top_frame()  {
   top.title.document.writeln("Top Frame<BR>");
function output_bottom_frames()  {
    top.bottom.document.writeln("Bottom Frame<BR>");

<frameset rows="60,1*" border=1 framespacing=0 frameborder=0 framepadding=0
marginwidth=0 marginheight=0>
<frame src="javascript:top.output_top_frame();" marginheight=0 marginwidth=0
scrolling=no noresize frameborder=no name=title>
<frame src="javascript:top.output_bottom_frames();" marginheight=0 marginwidth=0
scrolling="no" name=bottom>
*** Bug 227055 has been marked as a duplicate of this bug. ***


14 years ago
Blocks: 227087
*** Bug 235675 has been marked as a duplicate of this bug. ***
*** Bug 251655 has been marked as a duplicate of this bug. ***
*** Bug 178366 has been marked as a duplicate of this bug. ***

Comment 20

13 years ago
I've just encountered this problem too! Reproducible even in Mozilla 1.8a6. I
found that it seems only location.replace is affected. When I use location.href
= "" or src = "", there is no problem.

In fact, any kind of frames are affected. No matter it is a <frame>, <iframe> or
<object type="any text/XML MIME type">.

I'll put my simple test case here which involves two nested iframes.

Comment 21

13 years ago
Created attachment 172486 [details]
Nested iframes with the inner iframe using location.replace

After unzipping the file, open a.html.
a.html includes an iframe that points to b.html
b.html includes an iframe pointing to Yahoo, and will be "location.replace"d to

See how the throbber rolls like crazy when it finished loading. The stop button
doesn't work too. But apparently it has stopped loading any more file. Just
that the throbber goes crazy.

Comment 22

12 years ago
Is this what I'm seeing?


iframe URL, according to Adblock:


Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050928
Firefox/1.4 ID:2005092806

The tab's throbber never stops spinning even though the main throbber does and
the loading statusbar disappears from the bottom right corner of the window.

Having Adblock block "http://**&url=*" to try to stop the
iframe from loading doesn't fix it.

Comment 23

11 years ago
This bug still exists in both XHTML and HTML framed pages.
The only solution i've found can be achieved with the following JavaScript code AFTER the occurred event (any event that modified the DOM tree).

self.document.close(); // the modified DOM
top.document.close();  // the parent frameset page

NOTE: this will NOT work for XHTML pages that include the application/xhtml+xml since the DOM has no such thing as document.close() (write to document)

Comment 24

11 years ago
Here's one that also works with XHTML, use at own risk though.

try { // firefox frameset bug
} catch (e) { // self. fails using xhtml
	setTimeout(function(){ top.stop(); }, 5000);


11 years ago
Blocks: 39310
Fixed by checkin for bug 315056.
Last Resolved: 11 years ago
Depends on: 315056
Resolution: --- → FIXED

Comment 26

10 years ago
Is this bug supposed to be fixed in Firefox 2.x? I still have it in Firefox but not in Firefox 3.0b1.
This was fixed by the patch from bug 315056, which was checked in at 2006-10-18.
That means it went into the trunk, not on branch.
You need to log in before you can comment on or make changes to this bug.