Rename cookieURL to inheritedURL and add inheritedURL() to WebDocument

Rename cookieURL to inheritedURL and add inheritedURL() to WebDocument

Needed to make decisions based on the inherited URL in Chromium code,
https://codereview.chromium.org/226663003/

[robwu, 2014-04-22 13:23:01]

In https://codereview.chromium.org/226663003/, I need to know the inherited URL
of an about:blank frame to find out whether to insert a content script or not.

[abarth-chromium, 2014-04-22 17:36:21]

not lgtm

https://codereview.chromium.org/246433004/diff/1/Source/core/dom/Document.h
File Source/core/dom/Document.h (right):

https://codereview.chromium.org/246433004/diff/1/Source/core/dom/Document.h#n...
Source/core/dom/Document.h:760: // (inherited) URL, e.g. querying the cookie
database for the document's
You shouldn't be making security decisions based on this URL.  You should be
making security decisions based on the Document's SecurityOrigin.

[robwu, 2014-04-22 19:05:50]

https://codereview.chromium.org/246433004/diff/1/Source/core/dom/Document.h
File Source/core/dom/Document.h (right):

https://codereview.chromium.org/246433004/diff/1/Source/core/dom/Document.h#n...
Source/core/dom/Document.h:760: // (inherited) URL, e.g. querying the cookie
database for the document's
On 2014/04/22 17:36:21, abarth wrote:
> You shouldn't be making security decisions based on this URL.  You should be
> making security decisions based on the Document's SecurityOrigin.

I have just weakened the statement in the comment. Could you take another look?

The method is used to determine whether or not to insert an extension's content
script in an about:-frames, which requires knowledge about the frame's inherited
URL:

"matches": ["http://example.com/blank/*"],
"match_about_blank": true

[abarth-chromium, 2014-04-22 19:11:33]

I don't think we should add more clients of the cookieURL.  It's some goofy
thing we need to support in order to implement cookies correctly.  It's not
something we want to add more dependencies on.

To give you some more context, we used to have many URLs that were associated
with a Document.  Almost all the time, these URLs were the same, but in some
esoteric cases they'd be different.  In practice, people would pick an arbitrary
one and it would work most of the time.  In the esoteric case where it was
different from the others, the code would break.

Over time, we removed almost all of these URLs.  We're not able to remove
cookieURL because content depends on the esoteric way that it's different from
document.url.  That's unfortunate, but not something we want to spread any
further.

[robwu, 2014-04-22 19:16:52]

On 2014/04/22 19:11:33, abarth wrote:
> I don't think we should add more clients of the cookieURL.  It's some goofy
> thing we need to support in order to implement cookies correctly.  It's not
> something we want to add more dependencies on.
> 
> To give you some more context, we used to have many URLs that were associated
> with a Document.  Almost all the time, these URLs were the same, but in some
> esoteric cases they'd be different.  In practice, people would pick an
arbitrary
> one and it would work most of the time.  In the esoteric case where it was
> different from the others, the code would break.
> 
> Over time, we removed almost all of these URLs.  We're not able to remove
> cookieURL because content depends on the esoteric way that it's different from
> document.url.  That's unfortunate, but not something we want to spread any
> further.

Content script injection decisions are based on .url() because an extension
developer may restrict the set of URL patterns.
Do you know of any acceptable solution that offers the same ability for
about:-frames (using inherited URL)?

[abarth-chromium, 2014-04-22 20:44:14]

On 2014/04/22 19:16:52, robwu wrote:
> Content script injection decisions are based on .url() because an extension
> developer may restrict the set of URL patterns.
> Do you know of any acceptable solution that offers the same ability for
> about:-frames (using inherited URL)?

I'm not sure I understand enough of the problem you're trying to solve to find
an alternative solution.

[robwu, 2014-04-22 21:22:58]

On 2014/04/22 20:44:14, abarth wrote:
> On 2014/04/22 19:16:52, robwu wrote:
> > Content script injection decisions are based on .url() because an extension
> > developer may restrict the set of URL patterns.
> > Do you know of any acceptable solution that offers the same ability for
> > about:-frames (using inherited URL)?
> 
> I'm not sure I understand enough of the problem you're trying to solve to find
> an alternative solution.

Content scripts will only be inserted on pages that match the patterns as
declared in the manifest file
(https://developer.chrome.com/extensions/content_scripts#registration).
Currently, it is not possible for extensions to insert in about:blank, even
though an extension can access the about:blank frame by inserting a content
script in its parent document.

I've implemented insertion of content scripts in about:blank in
https://codereview.chromium.org/226663003/.
At the moment, it generates an URL from the securityOrigin() of the about:blank
documents. The issue with this approach is that only origins can be matched, not
specific paths.

So, the main issue is the inability to insert in about:blank frames based on the
path of its parent document. Do you know of an alternative besides not
supporting paths?

[abarth-chromium, 2014-04-22 23:44:05]

On 2014/04/22 21:22:58, robwu wrote:
> Do you know of an alternative besides not supporting paths?

I'm sorry, but I don't have the bandwidth to help you solve this problem.  I
don't think we want to use the cookieURL for the reasons described above.

[robwu, 2014-04-23 08:20:07]

On 2014/04/22 23:44:05, abarth wrote:
> On 2014/04/22 21:22:58, robwu wrote:
> > Do you know of an alternative besides not supporting paths?
> 
> I'm sorry, but I don't have the bandwidth to help you solve this problem.  I
> don't think we want to use the cookieURL for the reasons described above.

Ok, I will stick to the origin-only checks.
Thanks for the review!