Closed Bug 299756 Opened 19 years ago Closed 2 years ago

Recursive frames hang Firefox

Categories

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

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: DarkDespair5, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: hang, testcase)

Attachments

(3 files, 1 obsolete file)

Testcase from url
1.02 KB, text/html
Details
TESTCASE: Recursive embedding
102 bytes, text/html
Details
screenshot of local copy of testcase.html loaded (with devtools open to show just one level of recursive-load having succeeded)
69.62 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

This has not currently been an issue with content sites, but you should be
informed that when frames are dynamic and/or rapidly changing, Firefox will crash.
My suggestion is to add a delay when generating/resizing frames, or add a
command to FF that will exit/stop the page when frames change more than X times
in X timeframe. The "View Source" obtained by disabjung JavaScript and visiting
the page is:

//////START CODE////
 <html><head><title>Your browser WILL crash</title></head>
<script><!--

// This page was written by (and copyright) Chogg (http://www.arq.net/~chogg),
January 2002,
// explicitly for Josh's browser crash site (http://www.newdream.net/crash/).
Any other use
// is strictly prohibited unless Josh says so at the web address above. As the
author, I
// (Chogg) hereby give Josh all legal rights to this work, as it was entirely
inspired by
// his previous browser crashing CGI script using the same concept. As of this
notice, this
// text and the code herein is copyright Josh, 2002.


var fc = location.search;
if (fc.length > 1) { fc = fc.substring(1); }
else { fc = 0; }

if (fc % 2 == 0) {
        document.write('<frameset rows=*,* bordercolor=blue>');
}
else {
        document.write('<frameset cols=*,* bordercolor=red>');
}
fc ++;
document.write('<frame src=js2.html?' + fc + ' frameborder=0 scrolling=no>');
document.write('<frame src=js2.html?' + fc + ' frameborder=1 scrolling=no>');
document.write('</frameset>');
// -->
</script></html>
/////END CODE////

When I create a page with that code and open it, FF will NOT crash.

Reproducible: Always

Steps to Reproduce:
1.Visit http://newdream.net/crash/js2.html,
2.Wait a few seconds.
3.Try to do anything.
Actual Results:  
Firefox crashed.

Expected Results:  
Crash. This is an exploit page.

None.
Keywords: crash
Bug 8065 seems related.
Hmm... WFM in same version as reporter (FF 1.0.4). I'll double-check in Deer
Park when I get to my other machine. Perhaps reporter has low memory. It stops
after 9 or 10 levels of framesets for me, and I had 512 frames displayed on my
screen when all was set and done. Takes a while to rerender when I switch to
that frame, but it renders nonetheless. I'm writing this comment as this is open
in another tab in my browser.
Okay tested on Deer Park (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050531 Firefox/1.0+)

Moz seemed to hang while it was rendering. Switching to another window and then
back seemed to cause it to eventually properly hang. It's ugly behavior, but not
a crash. It resolves itself eventually, but it causes issues. Then again, there
are lots of ways a page can bring a browser to its knees for a while with
infinite (or near infinite) data
Keywords: crash → hang
Summary: Recursive frames crash Firefox. (NOTE: Firefox will still be open, but all buttons/actions are rendered nonfunctional) → Recursive frames hang Firefox
Attached file Testcase from url — 

  

  



    
    

    
  
Mozilla's performance here is awful, but IE6 just completely freezes on me.
Opera8's performance seems slightly better than Mozilla's.

  

  


Component: General → Layout: HTML Frames
Product: Firefox → Core
QA Contact: general → layout.html-frames
Version: unspecified → Trunk
Keywords: testcase

    
    

    
  
No hang and no crash with the testcase on Mozilla 1.7.8 Linux.

  

  



    
    

    
  
(In reply to comment #3)
> Okay tested on Deer Park (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8b2) Gecko/20050531 Firefox/1.0+)
> 
> Moz seemed to hang while it was rendering. Switching to another window and then
> back seemed to cause it to eventually properly hang. 

Oops. I meant to say "properly render". So to recap, the observed behavior was
unresponsiveness until I switched to and from that window, when it then rendered
(slowly but surely).



  

  



    
    

    
  
The testcase seems to be missing files, and the URL in the URL bar times out....

That said, this is basically bug 285395

  

  


Depends on: 285395

    
  
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
I was playing around with Gran Paradiso 3.0a6rc2 and discovered a something about how Firefox deals with embedding that related to this bug:

You can typically only have 2 levels of embedding (ie. an iframe in an iframe).  This seems to be the case with <object>, <embed>, and <iframe>.  However, if you have an <object> that points to the original document and has a 1px border, Firefox will get caught in a recursive loop and bloat until the user decides to force quit or the system can no longer take the load.

Here is the offending tag that causes the recursion, assuming the containing document is called index.html:
<object data="index.html" border="1px"></object>

The results I experienced on my system were that firefox took 50% of my cpu usage (100% of 1 core) and bloated to 350MB after about 30 minutes of watching task manager before I got bored and forced quit.  Firefox probably would have been more than happy to munch away at more of my ram had I not stopped it.

I have attached a test case that simulates what I saw.

Note:  This only affects Firefox 3.0-based builds as far as I can tell.  Firefox 2.0.0.4 only allows for a single level of recursion (ie. one layer of embedding within the parent layer of embedding).  I saw this on both GP 3.0a6 rc2 and the latest nightly trunk from June 29, 2007.

  

  



    
    

    
  

      
      
      
      

        Attached file
          
        TESTCASE: Recursive embedding  (obsolete)
        — 
      

    


  

  

  



    
    

    
  


  

  

  



        Attachment #270431 -
        Attachment is obsolete: true

    
    

    
  
OK, my test case does not work in the context of bugzilla due to linking problems.  Please copy and past the following code into a local html file called testcase.html.  You will see the bug then.  Alternatively, you can open the test case and either view source > copy code or save it as testcase.html locally.  Here is the code:

<html>
   <head>
   </head>
   <body>
      <object border="1px" data="testcase.html"></object>
   </body>
</html>

Also, I have not been able to confirm or debunk this on any other platform than Windows XP so far.

  

  



    
    

    
  
Anthony: The bug you're describing can't be this bug, since you say this only affects firefox 3 builds, and this was originally reported in a firefox 1.0 build. Also, the original description uses <frame>, and you say yours only works with <object>. 

Please file a separate bug describing your issue to make sure it doesn't get lost tangled up with the original bug here.

  

  



    
    

    
  
Done.  See bug 386599.

  

  



    
    

    
  
I can't believe this bug has been around for so long. 

I have managed to create similar crash using recursive iframes ( http://crashbrowser.j38.eu ). This crashes the current version of Firefox Lorentz, IE8 and Opera. Chrome & Safari are immune to the crash.

Firefox developers probably don't see any importance of fixing this bug. That is why there are many have switched to webkit-based browsers (Chrome & Safari) due to their stability and HTML5 support.

  

  



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

    
    

    
  
(In reply to u279076 from comment #12)




OK, my test case does not work in the context of bugzilla due to linking

problems.  Please copy and past the following code into a local html file

called testcase.html.  You will see the bug then.




No issues these days. We do load the file to one level of recursion, and we appear to stop after that point.



  

  


Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME

    
    

    
  
oh, per comment 13-14, I guess that one was spun off to another bug.


The original testcase (renamed to js2.html and loaded from a local web server) does still seem to recursively split itself to make a many-column "grid" of frames, but it seems to eventually stop without crashing Firefox on my machine.  So: still seems to be WFM.



  

  



    
    

    
  
For reference, here's a profile of me loading a locally hosted copy of the original testcase -- Martijn's attachment here: https://share.firefox.dev/3AS1JQW


We take about 20 seconds to load the page (doing a recursive spiral) and then we settle into a steady/done state, without crashing.



  

  



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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: