Recursive frames hang Firefox




14 years ago
3 months ago


(Reporter: DarkDespair5, Unassigned)


(Depends on: 1 bug, {hang, testcase})

Windows XP
hang, testcase

Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)



14 years ago
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>

// This page was written by (and copyright) Chogg (,
January 2002,
// explicitly for Josh's browser crash site (
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 =;
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>');
// -->
/////END CODE////

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

Reproducible: Always

Steps to Reproduce:
2.Wait a few seconds.
3.Try to do anything.
Actual Results:  
Firefox crashed.

Expected Results:  
Crash. This is an exploit page.



14 years ago
Keywords: crash
Bug 8065 seems related.

Comment 2

14 years ago
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.

Comment 3

14 years ago
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


14 years ago
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
Created attachment 188418 [details]
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

Comment 6

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

Comment 7

14 years ago
(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
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 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.
Created attachment 270431 [details]
TESTCASE: Recursive embedding
Created attachment 270432 [details]
TESTCASE: Recursive embedding
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:

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

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

Comment 13

12 years ago
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.

Comment 15

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

I have managed to create similar crash using recursive iframes ( ). 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.


3 months ago
Product: Core → Core Graveyard


3 months ago
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.