Closed
Bug 1088183
Opened 10 years ago
Closed 10 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•10 years ago
|
Assignee | ||
Updated•10 years ago
|
tracking-e10s:
--- → ?
Updated•10 years ago
|
Assignee: nobody → mmc
Assignee | ||
Comment 1•10 years ago
|
||
Assignee | ||
Comment 2•10 years ago
|
||
Not ready for review, waiting for bug 1049299 to land to avoid rebase race.
Assignee | ||
Comment 3•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8512821 -
Attachment is obsolete: true
Assignee | ||
Comment 4•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=2f3b06f35786
Assignee | ||
Updated•10 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•10 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•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=714d1b680e5b
Assignee | ||
Comment 6•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8512978 -
Attachment is obsolete: true
Assignee | ||
Comment 7•10 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•10 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•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=32cc5b71625a
Assignee | ||
Comment 10•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=e9af003527c0
Assignee | ||
Comment 11•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=9cfad774b073
Assignee | ||
Comment 12•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=45b9068c5a33
Assignee | ||
Comment 13•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8513113 -
Attachment is obsolete: true
Assignee | ||
Comment 14•10 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•10 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•10 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•10 years ago
|
||
Assignee | ||
Comment 18•10 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•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=7e38cdf03314
Assignee | ||
Comment 20•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=5c7aa59cebf7
Assignee | ||
Comment 21•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8518329 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8514003 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8518599 -
Flags: review+
Assignee | ||
Comment 22•10 years ago
|
||
Try is green: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=8256d9635d89
Keywords: checkin-needed
Assignee | ||
Comment 23•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8518599 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8518601 -
Flags: review+
Assignee | ||
Comment 24•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/f129b17f9067
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 25•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f129b17f9067
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•