Closed
Bug 1088183
Opened 11 years ago
Closed 11 years ago
[e10s] make top window URI available in the parent http channel
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
| Tracking | Status | |
|---|---|---|
| e10s | m4+ | --- |
People
(Reporter: mmc, Assigned: mmc)
References
Details
Attachments
(1 file, 6 obsolete files)
From netwerk/base/src/nsChannelClassifier:
nsCOMPtr<nsIDOMWindow> win;
rv = thirdPartyUtil->GetTopWindowForChannel(aChannel, getter_AddRefs(win));
NS_ENSURE_SUCCESS(rv, rv);
nsCOMPtr<nsIURI> uri;
rv = thirdPartyUtil->GetURIFromWindow(win, getter_AddRefs(uri));
This code is used to check the allowlist for tracking protection. It doesn't really need GetTopWindowForChannel, it just needs GetURIForTopWindow (which doesn't exist in the idl)
| Assignee | ||
Updated•11 years ago
|
| Assignee | ||
Updated•11 years ago
|
tracking-e10s:
--- → ?
Updated•11 years ago
|
Assignee: nobody → mmc
| Assignee | ||
Comment 1•11 years ago
|
||
| Assignee | ||
Comment 2•11 years ago
|
||
Not ready for review, waiting for bug 1049299 to land to avoid rebase race.
| Assignee | ||
Comment 3•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Attachment #8512821 -
Attachment is obsolete: true
| Assignee | ||
Comment 4•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Summary: [e10s] mozThirdPartyUtil.GetTopWindowForChannel isn't available in the parent process → [e10s] make top window URI available in the parent process
| Assignee | ||
Updated•11 years ago
|
Summary: [e10s] make top window URI available in the parent process → [e10s] make top window URI available in the parent http channel
| Assignee | ||
Comment 5•11 years ago
|
||
| Assignee | ||
Comment 6•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Attachment #8512978 -
Attachment is obsolete: true
| Assignee | ||
Comment 7•11 years ago
|
||
Comment on attachment 8513113 [details] [diff] [review]
Propagate the top window URI to the parent http channel through HttpChannelOpenArgs
Review of attachment 8513113 [details] [diff] [review]:
-----------------------------------------------------------------
This change calculates the top window URI in HttpChannelChild and saves it in the to nsHttpChannel through HttpChannelOpenArgs.
Attachment #8513113 -
Flags: review?(mrbkap)
Attachment #8513113 -
Flags: review?(jduell.mcbugs)
| Assignee | ||
Comment 8•11 years ago
|
||
Comment on attachment 8513113 [details] [diff] [review]
Propagate the top window URI to the parent http channel through HttpChannelOpenArgs
Hmm, I thought I fixed the serializing null principals bug after talking to Blake yesterday but it is still showing up in my try run.
Attachment #8513113 -
Flags: review?(mrbkap)
Attachment #8513113 -
Flags: review?(jduell.mcbugs)
| Assignee | ||
Comment 9•11 years ago
|
||
| Assignee | ||
Comment 10•11 years ago
|
||
| Assignee | ||
Comment 11•11 years ago
|
||
| Assignee | ||
Comment 12•11 years ago
|
||
| Assignee | ||
Comment 13•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Attachment #8513113 -
Attachment is obsolete: true
| Assignee | ||
Comment 14•11 years ago
|
||
Comment on attachment 8514003 [details] [diff] [review]
Propagate the top window URI to the parent http channel through HttpChannelOpenArgs
OK, try is looking better. The broken build in linux dbg is due to a missing include that only matters for non-unified build.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=45b9068c5a33
Attachment #8514003 -
Flags: review?(mrbkap)
Attachment #8514003 -
Flags: review?(jduell.mcbugs)
Comment 15•11 years ago
|
||
Comment on attachment 8514003 [details] [diff] [review]
Propagate the top window URI to the parent http channel through HttpChannelOpenArgs
Review of attachment 8514003 [details] [diff] [review]:
-----------------------------------------------------------------
::: netwerk/base/src/nsChannelClassifier.cpp
@@ +148,5 @@
> // Tracking protection will be disabled so update the security state
> // of the document and fire a secure change event.
> + nsCOMPtr<nsIDOMWindow> win;
> + rv = thirdPartyUtil->GetTopWindowForChannel(aChannel, getter_AddRefs(win));
> + NS_ENSURE_SUCCESS(rv, rv);
So I'm confused about what happens here on the parent for an e10s channel. Looks like you'll get a null TopWindow and return an error. Is that what you want? Maybe a comment would be nice.
::: netwerk/protocol/http/HttpBaseChannel.cpp
@@ +1342,5 @@
> + util = do_GetService(THIRDPARTYUTIL_CONTRACTID);
> + }
> + if (util) {
> + // In e10s, this must be computed in the child. The parent gets the top
> + // window URI through HttpChannelOpenArgs.
Move this comment up to the "if (!mTopWindowURI)" comment, so:
// Only compute the top window URI once. (In e10s we compute it on the child, then set mTopWindowURI on the parent via HttpChannelOpenArgs)
::: netwerk/protocol/http/HttpChannelChild.cpp
@@ +1498,5 @@
> mThirdPartyFlags |= thirdParty ?
> nsIHttpChannelInternal::THIRD_PARTY_PARENT_IS_THIRD_PARTY :
> nsIHttpChannelInternal::THIRD_PARTY_PARENT_IS_SAME_PARTY;
> + nsCOMPtr<nsIURI> uri;
> + (void)GetTopWindowURI(getter_AddRefs(uri));
No need to put (void) in front of functions that ignore return value. That's ancient K&R C style formatting :) That said, if you think it helps indicate expressly that we don't care about return value, I'm ok with leaving it. But we don't use that idiom much in necko.
Attachment #8514003 -
Flags: review?(jduell.mcbugs) → review+
Comment 16•11 years ago
|
||
Comment on attachment 8514003 [details] [diff] [review]
Propagate the top window URI to the parent http channel through HttpChannelOpenArgs
Review of attachment 8514003 [details] [diff] [review]:
-----------------------------------------------------------------
This looks good to me.
::: netwerk/protocol/http/HttpBaseChannel.cpp
@@ +1332,5 @@
> // HttpBaseChannel::nsIHttpChannelInternal
> //-----------------------------------------------------------------------------
>
> NS_IMETHODIMP
> +HttpBaseChannel::GetTopWindowURI(nsIURI **aTopWindowURI)
I'm not thrilled with this, but I don't really see a better way of doing it.
@@ +1340,5 @@
> + // Only compute the top window URI once.
> + if (!mTopWindowURI) {
> + util = do_GetService(THIRDPARTYUTIL_CONTRACTID);
> + }
> + if (util) {
I don't really see a reason to pull this out of the previous if statement.
::: netwerk/protocol/http/HttpChannelChild.cpp
@@ +1498,5 @@
> mThirdPartyFlags |= thirdParty ?
> nsIHttpChannelInternal::THIRD_PARTY_PARENT_IS_THIRD_PARTY :
> nsIHttpChannelInternal::THIRD_PARTY_PARENT_IS_SAME_PARTY;
> + nsCOMPtr<nsIURI> uri;
> + (void)GetTopWindowURI(getter_AddRefs(uri));
It's a little cleaner to use |unused <<| instead of (void).
::: netwerk/protocol/http/nsHttpChannel.h
@@ +151,5 @@
> return NS_OK;
> }
>
> + nsresult SetTopWindowURI(nsIURI* aTopWindowURI) {
> + mTopWindowURI = aTopWindowURI;
Nit: this file is inconsistent, but the modeline says to use 4-space tabs.
Attachment #8514003 -
Flags: review?(mrbkap) → review+
| Assignee | ||
Comment 17•11 years ago
|
||
| Assignee | ||
Comment 18•11 years ago
|
||
Comment on attachment 8518329 [details] [diff] [review]
Propagate the top window URI to the parent http channel through HttpChannelOpenArgs (
Review of attachment 8518329 [details] [diff] [review]:
-----------------------------------------------------------------
Address comments, thanks for the reviews!
Attachment #8518329 -
Flags: review+
| Assignee | ||
Comment 19•11 years ago
|
||
| Assignee | ||
Comment 20•11 years ago
|
||
| Assignee | ||
Comment 21•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Attachment #8518329 -
Attachment is obsolete: true
| Assignee | ||
Updated•11 years ago
|
Attachment #8514003 -
Attachment is obsolete: true
| Assignee | ||
Updated•11 years ago
|
Attachment #8518599 -
Flags: review+
| Assignee | ||
Comment 22•11 years ago
|
||
Keywords: checkin-needed
| Assignee | ||
Comment 23•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Attachment #8518599 -
Attachment is obsolete: true
| Assignee | ||
Updated•11 years ago
|
Attachment #8518601 -
Flags: review+
| Assignee | ||
Comment 24•11 years ago
|
||
| Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Comment 25•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•