"HTTP/2 and SPDY indicator" add-on doesn't work with e10s (Add CPOW for nsILoadContext.associatedWindow?)

RESOLVED FIXED

Status

()

Firefox
Extension Compatibility
RESOLVED FIXED
3 years ago
a year ago

People

(Reporter: Grant, Unassigned)

Tracking

(Blocks: 1 bug, {addon-compat})

33 Branch
Other
Android
addon-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Android; Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 (Nightly/Aurora)
Build ID: 20140718030202

Steps to reproduce:

E10s enabled nightly with spdy indicator addon should show in the awesome bar an icon that indicates if the page uses spdy.


Actual results:

No icon shows


Expected results:

Icon should have shown. I'm filing this bug on my Android phone, but it is for e10s desktop
hi Cheng, your SPDY Indicator add-on doesn't work with Firefox's e10s (multi-process) mode.

STEPS TO REPRODUCE:
1. Install Firefox Nightly: https://nightly.mozilla.org/
2. Install SPDY Indicator add-on.
3. e10s is disabled by default. Confirm that SPDY Indicator works in Firefox Nightly as expected before enabling e10s.
4. Now enable e10s by setting the about:config pref browser.tabs.remote.autostart to true.
5. Restart Firefox Nightly. When e10s is enabled, Firefox's tab titles will be underlined.
6. Reload the same SPDY website.

RESULT:
The website loads but the SPDY icon does not appear in the Awesome Bar. If you open the Browser Console (in the Tools > Web Developer > Browser Console, not Web Console), you will see the following error (many times):

NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsILoadContext.associatedWindow] indicator.jsm:25

When e10s is enabled, add-ons run in the privileged chrome/parent process and web content runs in the content/child process. I think you will need to find a different way to get the chrome window from a content window. This blog post has more information about e10s for add-on developers:

http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/
Blocks: 905436
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Component: Untriaged → Extension Compatibility
Ever confirmed: true
Flags: needinfo?(chengsun9)
Summary: Spdy indicator doesn't work with e10s → SPDY Indicator doesn't work with e10s
Hey Ally, here's an example of an add-on that uses the associatedWindow thing we talked about last week (related to http-on-* observers, although I don't know if that's what this one is doing).
Ally: the SPDY Indicator code is on GitHub. It is listening for http-on-*-response

https://github.com/chengsun/moz-spdy-indicator/blob/master/chrome/content/indicator.jsm
tracking-e10s: ? → +
hi Cheng, if you have any questions about add-on support for multiprocess Firefox (e10s), just drop by the #e10s IRC channel on irc.mozilla.org. MDN also has a good introduction:

https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox
Flags: needinfo?(chengsun9)
Keywords: addon-compat
Ally: can we add a shim for nsILoadContext.associatedWindow? This property seems to be the cause of many add-on problems with e10s. SPDY Indictator here is just a simple example.
Flags: needinfo?(ally)
It's still an object, so we'd need a cpow for it. Shims are only for functions in js. 

Lets nom for triage and see if we want to add another chrome cpow?
Flags: needinfo?(ally)
tracking-e10s: + → ?
Summary: SPDY Indicator doesn't work with e10s → "SPDY Indicator" add-on doesn't work with e10s (Add CPOW for nsILoadContext.associatedWindow?)
tracking-e10s: ? → +
Depends on: 1108827
There was an update released back in November 26th. Is the add-on still broken with e10s?
SPDY Indicator 2.2 is still broken for me:

NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsILoadContext.associatedWindow] indicator.jsm:25:0
Summary: "SPDY Indicator" add-on doesn't work with e10s (Add CPOW for nsILoadContext.associatedWindow?) → "HTTP/2 and SPDY indicator" add-on doesn't work with e10s (Add CPOW for nsILoadContext.associatedWindow?)

Updated

2 years ago
Duplicate of this bug: 1180469

Comment 10

2 years ago
Still broken in Aurora today. 41.0a2 Notifying over AMO.

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX

Comment 11

2 years ago
Hi, why carry out a batch to WONTFIX?
Flags: needinfo?(arenlor)

Comment 12

2 years ago
(In reply to YF (Yang) from comment #11)
> Hi, why carry out a batch to WONTFIX?

It's what we determined today. If the dev hasn't responded within three weeks of being notified it'll be marked WONTFIX, and the addon marked as incompatible with e10s when it comes out. If the dev comes around we'll be happy to reopen and work with them.
Flags: needinfo?(arenlor)

Comment 13

a year ago
This has just been fixed in the latest version of the add-on, sent to AMO for review.
Awesome!
Resolution: WONTFIX → FIXED
You need to log in before you can comment on or make changes to this bug.