1042377 - [e10s] mozIThirdPartyUtil.isThirdPartyChannel isn't available in the parent process

Status: RESOLVED DUPLICATE of bug 1049299

(Core :: Networking, defect, P2)

Description

[[:mmc] Monica Chew (no longer reading bugmail)]

Note: implementation is in content/base/src but idl is defined in netwerk.

isThirdPartyChannel finds the channel's window and doesn't work in e10s windows.

http://mxr.mozilla.org/mozilla-central/source/content/base/src/ThirdPartyUtil.cpp#153

Comment 1

[[:mmc] Monica Chew (no longer reading bugmail)]

More generally I need a way to get the URI associated with the top window associated with an nsIChannel in the parent process.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Hey Monica, do you have any other uses for this than the third-party cookie setting code? I think that for that case, we should compute the "third-party-ness" of the request in the child and send the result up to the parent with the request and avoid having to do the computation in the parent at all.

If you have other uses, then I'll take another look at this bug more specifically.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Bug 1038756 paves the way for my proposal in comment 2.

Comment 4

[[:mmc] Monica Chew (no longer reading bugmail)]

(In reply to Blake Kaplan (:mrbkap) from comment #2)
> Hey Monica, do you have any other uses for this than the third-party cookie
> setting code? I think that for that case, we should compute the
> "third-party-ness" of the request in the child and send the result up to the
> parent with the request and avoid having to do the computation in the parent
> at all.
> 
> If you have other uses, then I'll take another look at this bug more
> specifically.

Yes, https://bugzilla.mozilla.org/show_bug.cgi?id=1039012 and https://bugzilla.mozilla.org/show_bug.cgi?id=1033871 rely on stuff from ThirdPartyUtil.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

That looks fine, actually. As long as we have a channel, we'll be able to get the "third-party-ness" that it was created with.

Comment 6

[Chris Peterson [:cpeterson]]

Moving old M2 P2 bugs to M4.

Comment 7

[Chris Peterson [:cpeterson]]

Move old M2's low-priority bugs to M6 milestone.

Comment 8

[Chris Peterson [:cpeterson]]

oops: old M2 P2 bugs should have been moved to new M4 milestone, not M6.

Comment 9

[[:mmc] Monica Chew (no longer reading bugmail)]

:jimm or :mrbkap, what's the proposed solution for this bug? I may have time to work on it. Also, could you tell me what m4+ means?

Thanks,
Monica

Comment 10

[Jim Mathies [:jimm]]

I don't fully understand the cookie problems we have, and we have about three bugs on them currently.. so I'll leave it to blake to explain that.

'm4' - milestone 4, this is the e10s teams way of tracking blocks of bugs. We're currently finishing up the m3 block:

m3 - https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_e10s&o1=equals&resolution=---&query_format=advanced&v1=m3%2B&list_id=11389286
m4 - https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_e10s&o1=equals&resolution=---&query_format=advanced&v1=m4%2B&list_id=11389288

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Hey Monica,

My patch in bug 1049299 actually fixes this bug as well (it makes mozIThirdPartyUtil.isThirdPartyChannel work on channels opened for content processes by computing the parent information for the channel and passing it up to the parent).