I don't know the last good changeset, but the ToolboxProcess file was touched only by Bug 993029 in last couple of days. While trying to start browser debugger, I get: 0:12.99 ************************************************************ 0:12.99 * Call to xpconnect wrapped JSObject produced this error: * 0:12.99 [Exception... "TypeError: ThreadActor is undefined'TypeError: ThreadActor is undefined' when calling method: [nsICommandLineHandler::handle]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_ JS_OBJECT)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] 0:12.99 ************************************************************ 0:18.89 ************************************************************ 0:18.89 * Call to xpconnect wrapped JSObject produced this error: * 0:18.89 [Exception... "[JavaScript Error: "this._dbgProcess is undefined" {file: "resource:///modules/devtools/ToolboxProcess.jsm" line: 234}]'[JavaScript Error: "this._dbgProcess is undefined" {f ile: "resource:///modules/devtools/ToolboxProcess.jsm" line: 234}]' when calling method: [nsIObserver::observe]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "nat ive frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: yes] 0:18.89 ************************************************************

The regressing change is: https://hg.mozilla.org/mozilla-central/rev/a6a7df40f00a Bug 997239 - Convert webconsole to a module. r=msucan It seems we have some kind implicit dependency problem that requires actors to be loaded in a certain order to expose globals from one actor that another one needs. I hope we can resolve this with explicit dependencies, as this is a pretty unfortunate situation at the moment.

Alex, please take a look at this. I don't think it's safe to depend on globals from script.js being loaded into DebuggerServer like this.

(In reply to J. Ryan Stinnett [:jryans] from comment #2) > Alex, please take a look at this. I don't think it's safe to depend on > globals from script.js being loaded into DebuggerServer like this. That's what we have been doing for ages :p The main issue behind moving the console actor to a module is that all *its* globals will be missing in the magic global scope. Like `devtools` which regressed b2g. ThreadActor should still be defined by the way it was defined before. I would say that somehow script.js isn't loaded( before) webbrowser.js for the browser debugger... Bug 997239 has been backed out. I'll address that in the next patch to come.

(In reply to Alexandre Poirot (:ochameau) from comment #3) > (In reply to J. Ryan Stinnett [:jryans] from comment #2) > > Alex, please take a look at this. I don't think it's safe to depend on > > globals from script.js being loaded into DebuggerServer like this. > > That's what we have been doing for ages :p > The main issue behind moving the console actor to a module is that all *its* > globals will be missing in the magic global scope. Like `devtools` which > regressed b2g. ThreadActor should still be defined by the way it was defined > before. I would say that somehow script.js isn't loaded( before) > webbrowser.js for the browser debugger... > > Bug 997239 has been backed out. I'll address that in the next patch to come. I realize it's been that way for some time. :) One great benefit of using a module loader is that you can explicitly declare your dependencies without re-loading a module every time it's required. If we're able to finally stuff script.js inside a module, then these other files like webconsole.js can require the script actor in their headers, so you know *for sure* that the things they need are available, instead of just hoping they are because of load ordering. It's never a good idea to depend on load order, especially when we already have so many different versions of what actors are actually loaded for different products (though Paul's cleaning that up a bit). Not totally sure right now why the load order is different in this case though...

Girish, please make sure this is working for you now in the latest Beta, http://beta.mozilla.org.

Also flagging for in-testuite. We should probably have tests for this so it doesn't re-regress.

Its working in release and beta.

(In reply to Girish Sharma [:Optimizer] from comment #7) > Its working in release and beta. Thank you