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
Mozilla's performance here is awful, but IE6 just completely freezes on me. Opera8's performance seems slightly better than Mozilla's.
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
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 126.96.36.199 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 270432 [details] TESTCASE: Recursive embedding
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.