[Webkit-unassigned] [Bug 39427] Increase limit on number of (i)frames from 200 to 1000.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=39427





--- Comment #10 from hans at chromium.org  2010-05-21 04:46:54 PST ---
Looking at FrameTree::uniqueChildName(), it seems there is head room for 20+ digit frame numbers (FrameTree.cpp:144). The comment just says three digits is the highest it gets in practice, but any unsigned 64-bit number will be fine. If we change the limit to 1000 or higher, we should update that comment, though.

I have been investigating other users of this number:
WebKit/mac/WebView/WebFrame.mm:1562
WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm:1094
WebCore/page/DOMWindow.cpp:1034
WebCore/loader/archive/cf/LegacyWebArchive.cpp:444
WebCore/loader/HistoryController.cpp:607
WebCore/bindings/js/JSDOMWindowCustom.cpp:{208,354}

None of these make any dangerous assumptions about the size of this number that I can see. The m_childCount member variable is not exposed other than through childCount(), and not used in any alarming way internally.

Then there is Page::frameCount(). Again, I have not been able to find uses that make dangerous assumptions about the size of that number.

RenderEmbeddedObject::isURLAllowed() looks to see if Page::frameCount() is < 200. It seems to me that it should use the same limit as HTMLFrameElementBase. Please correct me if I am mistaken here. And as the same number is used in these two places, it would make sense to introduce a constant for the limit somewhere (would Page be a good place?).


One idea would be to raise the limit to 1111 frames, with the purpose of exposing any potential problems I've missed and hoping the build bots or nightly build users will trigger it.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.