Open Bug 285395 Opened 16 years ago Updated 2 years ago

Proposal to rethink overall capping of frame trees (backoff)

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: bzbarsky, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted)

Right now we have an "overall" cap of 10-deep on frame trees.  We used to have a
cap on number of docshells per window as well, but took that out because it hurt
with many tabs and also hurt one of IBM's internal apps.

An idea I had for dealing with this was the following:

1)  Allow arbitrary depth of frame tree.
2)  Hard-cap at 10000 frames per root item of same type (so that adjacent tabs
    don't affect each other, and so that IBM is not too unhappy, and so that
    left to ourselves we cap at a finite amount of memory even when loading a
    malicious page).
3)  Once we're over some threshold for number of frames for the given content
    docshell subtree (read "tab"), start doing fallback.  That is, instead of
    LoadFrame directly calling loadURI on the docshell, have it set a timer to
    call later.  The more frames, the larger the timer delay.  The goal is to
    avoid freezing up the UI and allow the user to hit "stop" as desired.

I _think_ that if we choose the fallback threshold and speed right we can stay
responsive and not really degrade initial load performance too badly even on
that IBM app.

Thoughts?  Is this worth trying?
10000 sounds a bit high. With that many frames aren't we running a risk of using
up enough memory to make the user-system unstable due to low memory?
And even with a 1 second delay between frames that'll take almost 3 hours to
load, no user is going to wait that long anyway. How about 1000?

Other then that it sounds like a neat idea.
sicking, see bug 228829 comment 14.   Hence the 10,000 number.  I do realize it
would take forever to load, but the app involved doesn't put anything in most of
the frames, to start with.
Summary: Proposal to rethink overall capping of frame trees → Proposal to rethink overall capping of frame trees (backoff)
Blocks: 285951
Blocks: 312137
I'm still worried that opening 10000 frames is going to suck all the resources
from the system. Even with the problem mentioned in bug 228829 comment 14 only
approximatly 1 in every 20 frames is 'wasted'. With a cap of 1000 frames that
leaves you with 950 'real' frames. Does anyone (i.e. the domino app) really need
more then that?

IMHO it'd even be fine to remove that 25-frames-max limitation bringing the
limit up to a whopping 1000 real frames :)

> Does anyone (i.e. the domino app) really need more then that?

mkaply, do you know? Or can you find out?

> IMHO it'd even be fine to remove that 25-frames-max limitation

Already done -- bug 285394.
(In reply to comment #4)
> > Does anyone (i.e. the domino app) really need more then that?
> 
> mkaply, do you know? Or can you find out?

Unfortunately I can't really find out at this point. My wager would be that
would be enough frames.
Ok.  So let's do the 1000-total per root treeitem cap and remove the depth cap?
Good enough that you want to do it?  ;)  Or should I give it a shot?
I could do it if you're willing to wait a bit. I need to learn more about
nsDocShell land anyway.
I'm in no rush as long as we get to it by 1.9, and the more people know docshell
code the better, in my book.  ;)
Blocks: 299756
Duplicate of this bug: 420868
Duplicate of this bug: 408742
I just wanted to add this as an FYI for another application that this affects. Our business intelligence solution is based on SAP's BusinessObjects software. The dash-boarding technology within BusinessObjects apparently requires more than 10 nested IFrames and thus does not work in Firefox.

I also would like to thank everyone for all the effort that goes into this project.
Duplicate of this bug: 545641
We just ran into this limitation, and would like to see the cap raised so something like 25 nested inline frames.

I haven't run into a limit with IE, Chrome, or Safari, yet. Here's a screen shot 
of an application that uses nested inline frames: 

http://preview.tinyurl.com/yf3nxsf 

The application is part of a comprehensive Student Information System, 
which shows a list of students enrolled in a class.  The idea is to 
make classroom seating assignments by clicking a seat location - then 
selecting a student from a popup list. 
Inline frames are nested as follows: 

1. Enrolled Students Popup - within - 
2. Seating Assignments - within - 
3. Seating Sections - within - 
4. Class (Algebra 2) - within - 
5. Teacher's Gradebook (Kendall Andelin) - within - 
6. Fiscal Year & Term - within - 
7. School (Goblin High School) - within - 
8. District (Halloween Alley) - within - 
9. Work Area (Student Information) - within - 
10. OnePoint Portal 

Nested inline frames reflect hierarchical relationships between 
database tables and portal work areas.  The cool thing about nesting 
the frames is that users can drill down & navigate back up the 
hierarchy with a single click, while the frame preserves the state of 
the content therein.  Unfortunately we seem to have reached a limit 
with Firefox. 

Thanks for your consideration. 

-Nathan.
Just raising the cap to 25 without any other changes is equivalent to removing the cap altogether.  In particular, it would allow at least 2^24 frames in a given frame tree...  Unfortunately, it's not uncommon for miscoded sites to lead to just such exponential growth behavior.  So a mitigation strategy of _some_ sort is needed.

But yes, someone just needs to sit down and do it.  I'm happy to advise as needed.
Keywords: helpwanted
Hi,
Can this at least be set as configurable (by about:config settings) ?
This way plugin can change that or user can change with own risk?
It will save a lot of trouble.

Thanks,
Tal
Duplicate of this bug: 1367468
Hi,
Only FF does not support more than 10 nested frames!
Why don't fix this problem?

Thanks,
Hooter
Product: Core → Core Graveyard
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.