285395 - Proposal to rethink overall capping of frame trees (backoff)

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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?

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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 :)

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 5

[Mike Kaply [:mkaply]]

(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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Ok.  So let's do the 1000-total per root treeitem cap and remove the depth cap?

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sounds good to me.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Good enough that you want to do it?  ;)  Or should I give it a shot?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I could do it if you're willing to wait a bit. I need to learn more about
nsDocShell land anyway.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 13

[Mark]

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.

Comment 15

[Nathan Andelin]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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.

Comment 17

[Tal]

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

Comment 19

[Hooter]

Hi,
Only FF does not support more than 10 nested frames!
Why don't fix this problem?

Thanks,
Hooter

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

If I understand correctly this is about HTML frames, not layout frames. We have a pretty deep layout frame limit.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Yes, this is about <frame>/<iframe>.