Closed Bug 1113294 Opened 5 years ago Closed 5 years ago

[e10s] Getting tab from nsIHTTPChannel is always null

Categories

(Core :: Networking, defect)

37 Branch
x86
macOS
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1108827
Tracking Status
e10s + ---

People

(Reporter: josesigna, Unassigned)

References

Details

Attachments

(1 file)

3.29 KB, application/zip
Details
Attached file 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)
You didn't by any chance set the multiprocessCompatible flag for the add-on, did you?
Flags: needinfo?(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.
Flags: needinfo?(josesigna)
Blocks: e10s
Component: Untriaged → Networking
Product: Firefox → Core
I'm assuming this is a DOM-side problem and that our addon shims are supposed to be kicking in here or something.
Component: Networking → DOM
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.
Component: DOM → Networking
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.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1108827
You need to log in before you can comment on or make changes to this bug.