Closed Bug 1196288 Opened 4 years ago Closed 4 years ago

gcli throws various exception on b2g

Categories

(DevTools Graveyard :: Graphic Commandline and Toolbar, defect)

defect
Not set

Tracking

(firefox43 fixed)

RESOLVED FIXED
Firefox 43
Tracking Status
firefox43 --- fixed

People

(Reporter: ochameau, Unassigned)

References

Details

Attachments

(1 file)

Failed to load module gcli/types/file: ...
(NS_ERROR_FAILURE) [nsIProperties.get]
resource://gre/modules/devtools/gcli/util/filesystem.js :: line 37
at exports.createSystem/loadModule (resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/gcli/system.js:132:undefined)"1 system.js:132

Failed to load module devtools/toolkit/gcli/commands/calllog: Module `devtools/framework/target` is not found at resource:///modules/devtools/framework/target.js" "
    at exports.createSystem/loadModule (resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/gcli/system.js:132:undefined)"1 system.js:132

Failed to load module devtools/toolkit/gcli/commands/paintflashing: Module `devtools/framework/target` is not found at resource:///modules/devtools/framework/target.js" "
    at exports.createSystem/loadModule (resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/gcli/system.js:132:undefined)"1 system.js:132


Do we support gcli remotely, other than just remote tabs?
May be we should disable gcli actors on b2g/fennec until proper support?
These seem like new regressions.  When testing against Simulator 3.0 (the several months old one), I don't see such issues.

However, the case is definitely tricky, since we don't test it at all on b2g / Fennec.
Here are some open GCLI bugs that could be related:

Bug 1166425
Bug 1161131
Bug 1196189
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> However, the case is definitely tricky, since we don't test it at all on b2g
> / Fennec.

It's not that we don't *test* it at all. We don't even expose any way to do remote gcli, right?
I think we should disable it until we start exposing a client feature to connect gcli toolbar to remote targets.
(In reply to Alexandre Poirot [:ochameau] from comment #3)
> It's not that we don't *test* it at all. We don't even expose any way to do
> remote gcli, right?
> I think we should disable it until we start exposing a client feature to
> connect gcli toolbar to remote targets.

I believe Joe added a gcli command a while ago for sending commands to a remote server, but I can't find it right now. Perhaps it was related to the |context| command?
Flags: needinfo?(jwalker)
(In reply to Alexandre Poirot [:ochameau] from comment #3)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> > However, the case is definitely tricky, since we don't test it at all on b2g
> > / Fennec.
> 
> It's not that we don't *test* it at all. We don't even expose any way to do
> remote gcli, right?
> I think we should disable it until we start exposing a client feature to
> connect gcli toolbar to remote targets.

I should have been more specific before...  I am mainly thinking of the toolbox command buttons, most of which depend on GCLI.  Currently, many of them do not show up when enabled for a remote target or are broken if they do appear.

If you open a toolbox in WebIDE, you can check this behavior easily enough. I'd like to get these buttons working, so that things like rulers and screenshots are consistently available in any toolbox, even with a remote target.
(In reply to Panos Astithas [:past] from comment #4)
> (In reply to Alexandre Poirot [:ochameau] from comment #3)
> > It's not that we don't *test* it at all. We don't even expose any way to do
> > remote gcli, right?
> > I think we should disable it until we start exposing a client feature to
> > connect gcli toolbar to remote targets.
> 
> I believe Joe added a gcli command a while ago for sending commands to a
> remote server, but I can't find it right now. Perhaps it was related to the
> |context| command?

That was a thing, but I'm fairly sure I removed it when I added e10s support.
Flags: needinfo?(jwalker)
Here is a patch to fix various exception I've seen,
but I think we should also just prevent running all this code on b2g.
Why do we even try to load gcli actor?
It should be lazy. When we debug an app, we should start loading it.
Attachment #8653565 - Flags: review?(jwalker)
Attachment #8653565 - Flags: review?(jwalker) → review+
https://hg.mozilla.org/mozilla-central/rev/4cb79a78ecf5
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Comment on attachment 8653565 [details] [diff] [review]
fix exception - v1

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

::: toolkit/devtools/gcli/commands/calllog.js
@@ +8,5 @@
>  const {TargetFactory} = require("devtools/framework/target");
>  const l10n = require("gcli/l10n");
>  const gcli = require("gcli/index");
>  
> +loader.lazyRequireGetter(this, "TargetFactory", "devtools/framework/target", true);

This line is throwing in fx-team due to duplication of TargetFactory definition


console.error: 
  Failed to load module devtools/toolkit/gcli/commands/calllog: TypeError: can't redefine non-configurable property "TargetFactory"
console.error: 
  DevToolsLoader.prototype.lazyRequireGetter@resource://gre/modules/devtools/Loader.jsm:320:1
@resource://gre/modules/devtools/gcli/commands/calllog.js:12:1
exports.createSystem/system.addItemsByModule/</options.loader@resource://gre/modules/devtools/gcli/system.js:165:20
exports.createSystem/loadModule@resource://gre/modules/devtools/gcli/system.js:112:30
exports.createSystem/system.load/promises<@resource://gre/modules/devtools/gcli/system.js:210:16
exports.createSystem/system.load@resource://gre/modules/devtools/gcli/system.js:208:22
GcliActor<._getRequisition@resource://gre/modules/devtools/server/actors/gcli.js:253:32
GcliActor<.specs<@resource://gre/modules/devtools/server/actors/gcli.js:96:12
actorProto/</handler@resource://gre/modules/devtools/server/protocol.js:1013:19
DSC_onPacket@resource://gre/modules/devtools/server/main.js:1591:15
ChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/devtools/transport/transport.js:742:5
Pinging for the above issue ^
Flags: needinfo?(poirot.alex)
(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #13)
> Pinging for the above issue ^

Fixed in bug 1202973.
Flags: needinfo?(poirot.alex)
Sounds good, thanks!
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.