Jan Jongboom says in <https://groups.google.com/d/topic/mozilla.dev.b2g/BObPh_lSMCQ/discussion> that B2G Desktop is reporting this error on startup: -------------------------------------------------------------------------------- Error loading: resource://gre/modules/devtools/server/transport.js: ReferenceError: `Components` is not available in this context. Functionality provided by Components may be available in an SDK module: https://jetpack.mozillalabs.com/sdk/latest/docs/ However, if you still need to import Components, you may use the `chrome` module's properties for shortcuts to Component properties: Shortcuts: Cc = Components.classes Ci = Components.interfaces Cu = Components.utils CC = Components.Constructor Example: let { Cc, Ci } = require('chrome'); - Loader/load/descriptors<.Components@resource://gre/modules/commonjs/toolkit/loader.js:243 @resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/transport.js:8 loadSubScript@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:29 @resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:59 evaluate@resource://gre/modules/commonjs/toolkit/loader.js:223 load@resource://gre/modules/commonjs/toolkit/loader.js:257 require@resource://gre/modules/commonjs/toolkit/loader.js:359 @resource://gre/modules/devtools/dbg-server.jsm:23 -------------------------------------------------------------------------------- dbg-server.jsm line 23 calls devtools.require("devtools/server/main"); main.js line 59 loads transport.js as a subscript; and transport.js line 8 references Components, which is presumably the reference that the CommonJS module loader is complaining about. Although it isn't clear which context the loader thinks is missing Components, given that dbg-server.jsm is a JavaScript Module, which should have such a reference by default. And main.js explicitly imports it from the "chrome" pseudo-module.

I have a strong suspicion this is related to my changes in bug 910184. I'll take a a look.

Well, this was a strange and winding road, but I believe this is a good fix for now. We should definitely clean this up for real in the next week or so though! dbg-server.jsm has returned to its previous state prior to my patch from bug 910184. In server/main.js, you'll see there are careful checks to prevent the file from blowing up and ensure that the correct require type is used. I have verified that this patch makes the B2G debugging server work again. Additionally, I ran the debugger test suite locally. The features of the original patch from bug 910184 are still intact. Try push: https://tbpl.mozilla.org/?tree=Try&rev=e5fc8e073558

Previous try push wasn't very convincing since all the B2G builds failed... Rebased and new try push[1] looks much better. [1]: https://tbpl.mozilla.org/?tree=Try&rev=ca9976b027ad

This bug isn't only about b2g desktop, remote device debugging is also down.

https://hg.mozilla.org/integration/fx-team/rev/8e23707fc975 Any way to test this?

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #6) > https://hg.mozilla.org/integration/fx-team/rev/8e23707fc975 > > Any way to test this? can test it with a local build against Android or B2G. This needs proper unittesting.

Agreed, proper test automation is definitely needed here, so we can attempt to avoid this trouble in the future. We don't currently have a good automation story for the DebuggerServer on B2G, and it is complicated by the fact that mochitest-chrome is currently unavailable on B2G. Rob filed bug 912017 to investigate adding device connection tests to automation. Additionally, I've filed bug 912066 based on Alex's idea on how we might test via mochitest-plain.