89300 - Evil recursive frames hangs browser (nested frames crash)

Status: RESOLVED DUPLICATE of bug 136580

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

Description

[Seth Burgess]

This page (crafted when bored in the summer of 95) recursively calls itself
inserting itself into frames.

Probably no such thing as a good way to handle this, but it does have a
particularlly undesirable result for mozilla.

Comment 1

[Jesse Ruderman]

On Win98:
- In IE, the user interface becomes unresponsive and I have to ctrl+alt+del the 
browser.
- In Moz 06/22, the throbber keeps resetting, but the stop button does work.  
If I allow the page to keep loading, I get a crash after about 15 seconds.

See also bug 8065, "crash on infinitely recursive frames site", which is marked 
as having been fixed in March.

Comment 2

[Keyser Sose]

Marking NEW.

Comment 3

[Eric Pollmann]

This is probably causing a crash due to the much higher branching factor than 
in bug 8065 (where a single frame was nested recursively versus the exponential 
nesting of four frames, as in this case). The fix in 8065 was to limit the 
depth of frame nesting - perhaps the fix here is to limit the total number of 
frames as well.

Will look at this in the future...

Comment 4

[Jesse Ruderman]

I think the correct fix here would be to make Gecko not crash when it has too
many frames.  I think it's likely that fixing this crash for the
way-too-many-frames case will also fix other crashes.

Comment 5

[Jesse Ruderman]

On WinNT 4.0, I don't see a crash or hang, although *leaving* the site is very slow.

Comment 6

[Andrew Thompson]

This URL 

http://java.sun.com/products/java-media/speech/forDevelopers/jsapi-doc/index.html/

causes today's nightly Mozilla and NS 6.1 to go into an infinite recursive loop
of ever smaller nested frames Windows 2000, eventually leading to "This program
is not responding". ie, a hang which requires an "End Task" to get out of it.

Yes, the / on the end of the URL is there - it works fine without it. The / was
a typo on my part.

This page is interesting because it doesn't deliberately try to cause a
recursive nest as far as I can tell. There's a reference to a "doclet" when I
view source in IE, so perhaps some server side code is getting confused by the
slash.
Win2K IE 5.5sp1 nests around twice then stops nesting any further.

Regardless of any bugs in Sun's server side code, Mozilla should handle this in
a graceful fashion akin to what IE does.

Comment 7

[Jesse Ruderman]

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

Comment 8

[Kevin McCluskey (gone)]

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

Comment 9

[Brian 'netdragon' Bober]

Duplicate of bug 8065?

Comment 10

[Kevin McCluskey (gone)]

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

Comment 11

[Asa Dotzler [:asa]]

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

Comment 12

[Vadim Berezniker]

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

Comment 13

[Aleksander Adamowski]

Similar problem exists with OBJECT tags, see dup bug 139108 and bug 136580.

Comment 14

[Matthias Versen [:Matti]]

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

Comment 15

[Hanno Boeck]

None of the test-cases crashes my mozilla version 1.1.
Is this bug fixed or are the testcases gone?

Comment 16

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 17

[John Keiser (jkeiser)]

*** This bug has been marked as a duplicate of 136580 ***