Bug 50726

Summary: Need a way to get a WKBundleFrameRef from JS HTMLIFrameElement
Product: WebKit Reporter: Sam Weinig <sam>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, eric, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
Patch darin: review+

Sam Weinig
Reported 2010-12-08 17:49:17 PST
We need a way to get a WKBundleFrameRef from JS HTMLIFrameElement, for traversing a frame tree from JS evading security mechanisms.
Attachments
Patch (8.81 KB, patch)
2010-12-08 17:51 PST, Sam Weinig 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Sam Weinig
Comment 1 2010-12-08 17:51:03 PST
Created attachment 75996 [details] Patch
Darin Adler
Comment 2 2010-12-08 17:53:39 PST
Comment on attachment 75996 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=75996&action=review > WebKit2/WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.h:63 > + PassRefPtr<WebFrame> copyDocumentFrame(); > + PassRefPtr<WebFrame> copyHTMLFrameElementContentFrame(); > + PassRefPtr<WebFrame> copyHTMLIFrameElementContentFrame(); When the return type is a PassRefPtr, I’m not sure it makes all that much sense to use copy naming when there’s no actual copying going on. There’s no need to use the copy rule for naming when you have a smart pointer class involved.
Sam Weinig
Comment 3 2010-12-08 19:27:30 PST
Fixed in http://trac.webkit.org/changeset/73579.
WebKit Review Bot
Comment 4 2010-12-09 02:22:48 PST
http://trac.webkit.org/changeset/73579 might have broken GTK Linux 32-bit Release
Note You need to log in before you can comment on or make changes to this bug.