Closed Bug 998912 Opened 6 years ago Closed 6 years ago

Browser toolbox does not start.

Categories

(DevTools :: Debugger, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 31

People

(Reporter: Optimizer, Assigned: ochameau)

References

Details

(Keywords: regression)

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.
Flags: needinfo?(poirot.alex)
OS: Windows 7 → All
Hardware: x86_64 → All
(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.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(poirot.alex)
Resolution: --- → FIXED
Assignee: nobody → poirot.alex
Target Milestone: --- → Firefox 31
(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.
QA Whiteboard: [qa-]
Flags: needinfo?(scrapmachines)
Also flagging for in-testuite. We should probably have tests for this so it doesn't re-regress.
Flags: in-testsuite?
Its working in release and beta.
Flags: needinfo?(scrapmachines)
(In reply to Girish Sharma [:Optimizer] from comment #7)
> Its working in release and beta.

Thank you
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-]
Flags: qe-verify-
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.