Bug 111913 - [chromium] Helper Plugin does not have a URL for its Document
Summary: [chromium] Helper Plugin does not have a URL for its Document
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: David Dorwin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-08 18:41 PST by David Dorwin
Modified: 2013-03-09 08:56 PST (History)
6 users (show)

See Also:

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 an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Dorwin 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.
Comment 1 David Dorwin 2013-03-08 18:57:39 PST 
Created attachment 192325 [details]
Patch
Comment 2 Adam Barth 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.
Comment 3 David Dorwin 2013-03-08 20:27:27 PST 
Created attachment 192329 [details]
Patch
Comment 4 David Dorwin 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.
Comment 5 Adam Barth 2013-03-09 08:36:18 PST 
Comment on attachment 192329 [details]
Patch

ok
Comment 6 WebKit Review Bot 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>
Comment 7 WebKit Review Bot 2013-03-09 08:56:54 PST 
All reviewed patches have been landed.  Closing bug.