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/
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
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
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.
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?
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
Still broken in Aurora today. 41.0a2 Notifying over AMO.
Hi, why carry out a batch to WONTFIX?
(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.
This has just been fixed in the latest version of the add-on, sent to AMO for review.