1113294 - [e10s] Getting tab from nsIHTTPChannel is always null

Status: RESOLVED DUPLICATE of bug 1108827

(Core :: Networking, defect)

Description

[josesigna]

Attachment: sampe.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

0. Use Firefox Nightly with multiprocess enabled (e10s, electrolysis)
1. Build a basic extension using the Addon SDK
2. Add an http-on-modify-request observer
3. subject.QueryInterface(Ci.nsIHttpChannel);
4. Implement code in from
https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Tabbed_browser#Getting_the_browser_that_fires_the_http-on-modify-request_notification_(example_code_updated_for_loadContext)
to get the DOMwindow from the channel.




Actual results:

DOMwindow is always null


Expected results:

DOMwindow should have been returned. Which would have then allowed me to use
require("sdk/tabs/utils").getTabForWindow(DOMwindow.top)
to get the tab for the channel.

(See attached sample extension)

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

You didn't by any chance set the multiprocessCompatible flag for the add-on, did you?

Comment 2

[josesigna]

(In reply to Bill McCloskey (:billm) from comment #1)
> You didn't by any chance set the multiprocessCompatible flag for the add-on,
> did you?

I did not in this example, but I tested with and without the flag and it made no difference.

Comment 3

[Josh Matthews [:jdm]]

I'm assuming this is a DOM-side problem and that our addon shims are supposed to be kicking in here or something.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is the observer being added in the content process or the chrome process?  The chrome-side channels don't have an associated DOM Window, iirc.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This will be fixed by bug 1108827. However, the right way to do this now is to get topFrameElement off the load context, which will be a <browser> element. I think there's some way to get the tab from the <browser> in Jetpack.

Unfortunately, before Firefox 38, topFrameElement will be null in non-e10s. So you probably will need both paths for now, using topFrameElement first and then DOMWindow and getTabForWindow(DOMwindow.top) if that is null.