Closed Bug 386599 Opened 14 years ago Closed 14 years ago

Recursive <object> with border hangs Firefox

Categories

(Core :: Plug-ins, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: u279076, Assigned: smaug)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

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.

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.

I have attached a test case that simulates what I saw.  The test case cannot be run through bugzilla.  It must be saved and run locally.  Alternatively, you can copy the following code into an empty file called "testcase.html" and run it that way.

Test Case code:
<html>
   <head>
   </head>
   <body>
      <object border="1px" data="testcase.html"></object>
   </body>
</html>
is this a regression from 1.8?
Product: Firefox → Core
QA Contact: general → general
I am not sure when this regressed.  I will continue testing today to find that out.
Component: General → DOM
QA Contact: general → general
As far back in 1.9 as I can test (2007-05-09 nightly and 1.9a1 rc2), I can reproduce this bug.  This is not happening in 2004.  This could possibly be a regression back to 1.8 as Christian has suggested.
Component: DOM → General
QA Contact: general → general
This bug has been tested and witnessed on the latest nightly trunk on Linux as well.
On Windows, this regressed between 2005-09-21-07 and 2005-09-22-07, which would make this a regression from bug 1156, as biesi suggested.
Blocks: 1156
Component: General → Plug-ins
Keywords: regression, testcase
OS: Windows XP → All
QA Contact: general → plugins
Hardware: PC → All
Summary: Recursive <object> hangs Firefox → Recursive <object> with border hangs Firefox
Not too familiar with the code, but using frameloader's 
CheckForRecursiveLoad might be quite ok.
Attachment #270605 - Flags: review?(cbiesinger)
Comment on attachment 270605 [details] [diff] [review]
patch-like thing...

sr=bzbarsky for what it's worth.
Attachment #270605 - Flags: superreview+
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Assignee: nobody → Olli.Pettay
Flags: in-testsuite?
Comment on attachment 270605 [details] [diff] [review]
patch-like thing...

+      mChannel->GetURI(getter_AddRefs(uri));

all the rest of this function uses "chan", please use that here too.
Attachment #270605 - Flags: review?(cbiesinger) → review+
so does presence of a border actually make a difference here?
When I originally tested the bug, a border made a difference because the browser actually had to have something to render.  It may yield the same results if there was actually content in the frames to render.
This bug appears to be fixed.  I cannot reproduce it any longer on the latest nightly trunk (2007071604).  I have tested the testcase on both Windows XP and Linux i386.  The testcase just displays a small vertical black line in the page content and does not lock up Minefield.
this doesn't work for me on both a mac seamonkey debug build from today and a winxp nightly firefox build from today. I saved the file locally, opened it, and got, while not quite a hang, a recursive load that doesn't seem to ever stop. (I can still interact with firefox, it's just a bit slow)
I still got the recursion without the patch.
Checked in (using chan, not mChannel).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.