Open Bug 285395 Opened 16 years ago Updated 2 years ago
Proposal to rethink overall capping of frame trees (backoff)
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)
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?
Sounds good to me.
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. ;)
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.
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.
blocking2.0: --- → ?
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
Hi, Only FF does not support more than 10 nested frames! Why don't fix this problem? Thanks, Hooter
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.