Closed Bug 1161131 Opened 9 years ago Closed 8 years ago

GCLI command buttons have trouble with old servers (split console missing)

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jryans, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [polish-backlog][difficulty=medium])

In bug 1160345, we restored access to the inspect element and frame switcher for old servers, which is great!

However, the split console button remains missing.

As a test case, if I start Simulator 2.2 from WebIDE and connect to an app, the split console command button is missing and the server gives the error:

"Protocol error (unrecognizedPacketType): Actor conn0.child21/gcliActor11 does not recognize the packet type specs" protocol.js:20
onPacket threw an exception: Error: Server did not specify an actor, dropping packet: {"error":"unknownError","message":"Error occurred while creating actor 'undefined: TypeError: browser is undefined\nStack: exports.GcliActor<.initialize@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/gcli.js:1:952\nconstructor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/heritage.js:16:80\nObservedActorFactory.prototype.createActor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/common.js:13:99\nDebuggerServerConnection.prototype._getOrCreateActor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:81:53\nDSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:91:11\nChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/transport/transport.js:38:288\nLine: 1, column: 951"}
Stack: DebuggerClient.prototype.onPacket@resource://gre/modules/devtools/dbg-client.jsm:944:1
DebuggerTransport.prototype._onJSONObjectReady/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/transport/transport.js:471:9
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
Line: 944, column: 0

As bgrins mentions in bug 1160345 comment comment 12, one option would be to separate split console from GCLI altogether.  Another path is to resolve these errors with new client -> old server.
The main issue is that the old GCLI actor assumes access to the "browser" property.

So, basically this error seems to say "GCLI actor is not remote", as we already knew before bug 1128988.

It seems like we should:

* Detect support for remote GCLI, and only try to use it with a remote target if the new support exists
* Separate split console from GCLI, so it can keep working without it
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> * Separate split console from GCLI, so it can keep working without it

This is done by both "command-button-pick" and "command-button-frames" in the toolbox, but they are implemented in different ways.  The picker button is built entirely in JS via _buildPickerButton [0], while "command-button-frames" is sort of a hybrid, with the markup being loaded in toolbox.xul [1] and the command event and other things being attached in JS.  Both end up with code sort of littered throughout toolbox.js to manage state (see pickerButtonChecked and _updateFrames).  I'm not sure what the best approach is here but I'd like to at least avoid adding a third way of handling this, and at best converge on some kind of pattern for non-gcli buttons.

[0]: https://github.com/mozilla/gecko-dev/blob/a73745d7ebbcf8a6bb6db62aca3a22861c878232/browser/devtools/framework/toolbox.js#L748
[1]: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.xul#93
Priority: -- → P2
For simulators 2.1 and earlier, this issue appears to cause WebIDE to say "Operation timed out: opening toolbox" when opening the toolbox.  Strangely, simulator 2.2 does not cause this WebIDE behavior, even though it logs the same GCLI actor error.

For myself, these issues don't seem to prevent using the toolbox, but for an SO user[1] it sounds like they may prevent it from opening.

[1]: http://stackoverflow.com/questions/31471989/operation-timed-out-installing-and-running-app
Whiteboard: [devedition-40] → [polish-backlog]
Whiteboard: [polish-backlog] → [polish-backlog][difficulty=medium]
Given that this only affects FxOS (Fennec release is new enough to not be impacted), I think it's unlikely we'll make changes here anymore.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.