1179739 - Errors are thrown in the Browser Console each time the user enters Customize

Status: RESOLVED DUPLICATE of bug 1160162

(Firefox :: Toolbars and Customization, defect)

Description

[Andrei Vaida [:avaida]]

Reproducible on:
* Firefox 39.0 RC (build6: 20150630154324) - partially
* Aurora 40.0a2 (2015-06-29)
* Nightly 41.0a1 (2015-06-28)
* Nightly 42.0a1 (2015-07-01)

Affected platforms:
* Windows 10 Pro (x64) Insider Preview Build 10158
* Windows 8.1 Pro (x64)
* Ubuntu 14.04 (x64)
* Mac OS X 10.10.4

Steps to reproduce:
1. Launch Firefox.
2. Open the Browser Console.
3. Click menu and select "Customize". Check the Browser Console.

Expected results:
The user is able to enter customization mode without encountering any issues.

Actual results:
Two errors are thrown in the Browser Console each time the user enters or exits Customize:
-- by ReaderParent.jsm:168:0
> TypeError: win.gBrowser is undefined
-- by DevToolsUtils.js:58:0
> Handler function threw an exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js :: TabActor.prototype._docShellsToWindows/< :: line 1132"  data: no]
> Stack: TabActor.prototype._docShellsToWindows/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1132:11
> TabActor.prototype._docShellsToWindows@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1129:1
> TabActor.prototype._notifyDocShellsUpdate@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1155:19
> TabActor.prototype._onDocShellCreated/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1107:7
> makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
> Line: 1132, column: 0

Additional notes:
* This issue is only partially reproducible on Firefox 39.0 RC, because the only error thrown there is the one originating from DevToolsUtils.js:58:0.
* This seems to be a regression, as the errors are NOT thrown on Release 38.0.5 (20150525141253), I'll follow up with a regression range as soon as possible.

Comment 1

[:Gijs (he/him)]

In an epic 2-years-later comeback to this comment:

(In reply to Tim Taubert [:ttaubert] from bug 1018913 comment #22)
> Always me :'(

Yes, yes, always you. Sorry! :-(

Because!

This is still happening if you use the context menu of the navbar repeatedly to open (and then you close) customize mode. It seems that the code here:

https://dxr.mozilla.org/mozilla-central/rev/584870f1cbc5d060a57e147ce249f736956e2b62/browser/modules/ReaderParent.jsm#106-110

gets a browser which doesn't live in a window which is a browser.xul window.

This in turn turns out to happen because in the customization mode preloader, we create a highly magical <browser> inside some data: uri window thing that we can later swap into the tabbrowser when needed, via HiddenFrame.jsm. The issue being that we load all these frame scripts into said browser, and some of them do kind of assume that they are being used in 'tab-content' because the file is called tab-content.js .

The trivial fix here is to nullcheck win.gBrowser.

The less trivial fix is to critically examine whether we really need those frame scripts here, and why.

The even less trivial fix is to think about what the distinction between 'content.js' and 'tab-content.js' really is, if it makes sense, how, and audit everything in it (and the places where we listen to messages sent from there) to check whether they cope with special snowflakes such as HiddenFrame.jsm.


Thoughts?

Comment 2

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #1)
> This is still happening

Specifically:


TypeError: win.gBrowser is undefined ReaderParent.jsm:136:1

(script location pinched from beta, might be different on Nightly)

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

I don't think there's a really easy fix here, the basic model of preloading & swapping docShells isn't great. I think what we changed with bug 1077652 is a little better, maybe you should do the same for the customization tab?

When ensurePreload() is called (given a window) you could insert a <xul:browser> just like _createPreloadBrowser() does. When the user enters customization mode you would then just pick it up in addTab(). The browser doesn't have a linked tab, but it's almost the real thing.