1039586 - "this._paths is undefined" and no browsing abilities when using e10s with browser.tabs.remote.autostart set to false

Status: VERIFIED FIXED

(Firefox :: Extension Compatibility, defect)

Comment 1

[Mike Conley (:mconley) (:⚙️)]

STR:

1) In a new profile, open a new e10s window
2) Attempt to browse

ER:

Browsing capabilities.

AR:

The browser shows a blank document, and won't go anywhere.

Non-e10s windows appear to work fine.

This is in the Browser Console:

"this._paths is undefined" RemoteAddonsChild.jsm:89

So I suspect this is because our shims don't work with autostart disabled[1], and we're not accounting for that somewhere.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1007978#c13

Comment 2

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

Thanks for filing Mike. I suspect we just need to avoid initializing RemoteAddonsChild from browser-child.js if autostart is not enabled.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Bill McCloskey (:billm) from comment #2)
> Thanks for filing Mike. I suspect we just need to avoid initializing
> RemoteAddonsChild from browser-child.js if autostart is not enabled.

Cool - I think I can whip that up.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Attachment: Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r=?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r=?

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8457022 [details] [diff] [review]
Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r=?

So this does the trick - I had to make sure none of the singletons in RemoteAddonsChild got initted, otherwise they errored out when trying to call watch on NotificationTracker (which gets no paths when sending the "Addons:GetNotifications" message).

Instead, we init those singletons on the first time a RemoteAddonsChild is initted.

This appears to fix the bug, but I _am_ curious to know why these shims can't be made to work with autostart set to false... this would make add-on compat testing harder for our Nightly users who don't necessarily want to dive whole-hog into e10s land. (See https://bugzilla.mozilla.org/show_bug.cgi?id=1007978#c14).

Comment 7

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

Comment on attachment 8457022 [details] [diff] [review]
Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r=?

Review of attachment 8457022 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

::: toolkit/components/addoncompat/RemoteAddonsChild.jsm
@@ +253,5 @@
> +  makeReady: function() {
> +    NotificationTracker.init();
> +    ContentPolicyChild.init();
> +    ObserverChild.init();
> +    this._ready = true;

It might be clearer if this goes in the |if (!this._ready)| section.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Attachment: Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r+'d by billm.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8457057 [details] [diff] [review]
Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r+'d by billm.

Thanks for the review billm! Fixed.

I'm also requesting review from jimm, because I need a toolkit peer.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8457057 [details] [diff] [review]
Ensure no add-on shim code gets executed when browser.tabs.remote.autostart is false. r+'d by billm.

Thanks for the review billm! Fixed.

I'm also requesting review from jimm, because I need a toolkit peer.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Thanks!

https://hg.mozilla.org/integration/mozilla-inbound/rev/e1775897a13e

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e1775897a13e

Comment 14

[Bogdan Maris, Desktop QA]

Reproduced the initial issue on old Nightly (2014-07-16), verified that the issue is fixed on Windows 7 64bit, Ubuntu 14.04 64bit and Mac OS X 10.9.4 using latest Aurora and Firefox 33 beta 2.