Closed
Bug 1113294
Opened 10 years ago
Closed 9 years ago
[e10s] Getting tab from nsIHTTPChannel is always null
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1108827
Tracking | Status | |
---|---|---|
e10s | + | --- |
People
(Reporter: josesigna, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
application/zip
|
Details |
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)
Updated•10 years ago
|
Blocks: e10s-addons
tracking-e10s:
--- → +
Updated•9 years ago
|
Component: Untriaged → Networking
Product: Firefox → Core
Comment 3•9 years ago
|
||
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
Comment 4•9 years ago
|
||
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: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•