Closed Bug 143398 Opened 23 years ago Closed 17 years ago

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

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: a.garcia.urzainki, Assigned: john)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(5 files)

Various html files that demonstrate Frameset/Onload bug
2.78 KB, application/x-zip-compressed
Details
Testcase innerframe
317 bytes, text/html
Details
Testcase
186 bytes, text/html
Details
onload within frameset does not display message in Netscape Navigator 6.2.3
697 bytes, text/html
Details
Nested iframes with the inner iframe using location.replace
541 bytes, application/x-zip-compressed
Details 
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.
Browser, not engine ---> HTML Frames
Assignee: rogerl → jkeiser
Component: JavaScript Engine → HTMLFrames
QA Contact: pschwartau → amar
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:
window.frames["middle02"].location.replace(url);.

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

<html>
<head>
<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--");
   window.frames["middle02"].location.replace(url);
}
// -->
</script>

</head>
<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">
   </frameset>
</frameset>
</html>
Attached file Testcase innerframe — 

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase
        — 
      

    


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

    
    

    
  
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() )



    
    

    
  
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. :-)

    
  
Blocks: 152057

    
  
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

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

    
    

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

    
    

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

    
    

    
  


  
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?

    
    

    
  
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">
<html>
<head>
<title>fs1</title>
<script type="text/javascript">
<!--
function init () {
alert("fs1:frameset:loading done!");
}
// -->
</script>
</head>
<frameset rows="*,*" onload="init();">
<frame src="page1.html">
<frame src="fs2.html">
</frameset>
</html>

An inner frameset fs2.html:

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

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

And page1-4.html like:

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

If you load the URL http://www.ep.haufe.de/~jiranek/test_frameset/fs1.html
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 http://www.ep.haufe.de/~jiranek/test_frameset . My testing environment
is Win2000/Mozilla1.0.1. This expample works fine with InternetExplorer!


    
    

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

    
    

    
  
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

    
  
Status: NEW → ASSIGNED

    
  
Keywords: testcase
Priority: -- → P3
Target Milestone: --- → Future

    
    

    
  
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>");
}
</script>

<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>
</frameset>

    
    

    
  
*** Bug 227055 has been marked as a duplicate of this bug. ***
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. ***

    
    

    
  
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.

    
    

    
  


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

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.

    
    

    
  
Is this what I'm seeing?

URL:

http://money.cnn.com/2005/09/28/pf/debt/delinquencies/index.htm?cnn=yes

iframe URL, according to Adblock:

http://cl.cnn.com/ctxtlink/jsp/money-story.jsp?domId=contextualLinks&time=1127923725394&origin=money&site=cnn_moncredit_dyn_ctxt&category=moneycredit&url=http://robots.cnnfn.com/2005/09/28/pf/debt/delinquencies/index.htm

Build:

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://*.cnn.com/ctxtlink/*&url=*" to try to stop the
iframe from loading doesn't fix it.

    
    

    
  
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)

    
    

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

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

Blocks: 39310

    
    

    
  
Fixed by checkin for bug 315056.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Depends on: 315056
Resolution: --- → FIXED

    
    

    
  
Is this bug supposed to be fixed in Firefox 2.x? I still have it in Firefox 2.0.0.9 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.

    
  
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: