WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
111913
[chromium] Helper Plugin does not have a URL for its Document
https://bugs.webkit.org/show_bug.cgi?id=111913
Summary
[chromium] Helper Plugin does not have a URL for its Document
David Dorwin
Reported
2013-03-08 18:41:55 PST
WebHelperPluginImpl creates a Document using DocumentWriter, but it does not provide a URL to begin(). As a result, the Document does not have a URL, meaning the browser cannot make decisions based on the host. Since the Helper Plugin is working on behalf or an element, it should have the same origin as the element.
Attachments
Patch
(8.02 KB, patch)
2013-03-08 18:57 PST
,
David Dorwin
no flags
Details
Formatted Diff
Diff
Patch
(8.35 KB, patch)
2013-03-08 20:27 PST
,
David Dorwin
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
David Dorwin
Comment 1
2013-03-08 18:57:39 PST
Created
attachment 192325
[details]
Patch
Adam Barth
Comment 2
2013-03-08 20:04:05 PST
Comment on
attachment 192325
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=192325&action=review
> Source/WebKit/chromium/src/WebHelperPluginImpl.cpp:67 > + // Give the new document the same URL as the hose frame so that content > + // settings and other decisions can be made based on the correct origin. > + const WebURL& hostFrameURL = hostFrame->document().url();
Why do we pass in a hostFrame instead of a hostDocument?
> Source/WebKit/chromium/src/WebHelperPluginImpl.cpp:71 > + writer.begin(hostFrameURL);
Frames don't have URLs. Documents have URLs.
> Source/WebKit/chromium/src/WebViewImpl.cpp:168 > + > +
These changes look spurious.
David Dorwin
Comment 3
2013-03-08 20:27:27 PST
Created
attachment 192329
[details]
Patch
David Dorwin
Comment 4
2013-03-08 20:31:13 PST
Comment on
attachment 192325
[details]
Patch Thanks. Any concerns about how |url| is used while creating the Document or during its lifetime? During creation, it seems to mostly be important whether it is a plugin (i.e. foo.swf), which is not the case here. View in context:
https://bugs.webkit.org/attachment.cgi?id=192325&action=review
>> Source/WebKit/chromium/src/WebHelperPluginImpl.cpp:67 >> + const WebURL& hostFrameURL = hostFrame->document().url(); > > Why do we pass in a hostFrame instead of a hostDocument?
Done. No reason really. Now, it's a const ref, which is nice.
>> Source/WebKit/chromium/src/WebHelperPluginImpl.cpp:71 >> + writer.begin(hostFrameURL); > > Frames don't have URLs. Documents have URLs.
Done.
>> Source/WebKit/chromium/src/WebViewImpl.cpp:168 >> + > > These changes look spurious.
Done.
Adam Barth
Comment 5
2013-03-09 08:36:18 PST
Comment on
attachment 192329
[details]
Patch ok
WebKit Review Bot
Comment 6
2013-03-09 08:56:51 PST
Comment on
attachment 192329
[details]
Patch Clearing flags on attachment: 192329 Committed
r145319
: <
http://trac.webkit.org/changeset/145319
>
WebKit Review Bot
Comment 7
2013-03-09 08:56:54 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug