[App Manager] Cannot use Inspector to view app's DOM on Flame

VERIFIED FIXED in Firefox 34

Status

()

Firefox
Developer Tools: WebIDE
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: mikehenrty, Assigned: miker)

Tracking

unspecified
Firefox 34
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Since flashing the latest Gecko/Gaia onto my Flame, I can no longer use the Inspector in App Manager for any certified apps. It connects and can "Start" and "Debug" apps, but when going to the Inspector tab everything is blank and the inspect button does nothing. At least one other Gaia dev has the same issue. I also see a stack trace in logcat, which I will put in the comments.

BuildID: 20140828160238
    E/GeckoConsole( 1811): Content JS ERROR at resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:852 in Actor<.writeError: ReferenceError: gDevTools is not defined
    I/Gecko ( 1811): Message: ReferenceError: gDevTools is not defined
    I/Gecko ( 1811): Stack:
    I/Gecko ( 1811): exports.NodeActor<._hasEventListeners@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:298:9
    I/Gecko ( 1811): exports.NodeActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:248:7
    I/Gecko ( 1811): WalkerActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:1133:13
    I/Gecko ( 1811): types.addActorType/type<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:275:1
    I/Gecko ( 1811): RetVal<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:490:12
    I/Gecko ( 1811): Response<.write/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:643:1
    I/Gecko ( 1811): Response<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:641:23
    I/Gecko ( 1811): a
    I/GeckoDump( 1811): exports.NodeActor<._hasEventListeners@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:298:9
    I/GeckoDump( 1811): exports.NodeActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:248:7
    I/GeckoDump( 1811): WalkerActor<.form@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:1133:13
    I/GeckoDump( 1811): types.addActorType/type<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:275:1
    I/GeckoDump( 1811): RetVal<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:490:12
    I/GeckoDump( 1811): Response<.write/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:643:1
    I/GeckoDump( 1811): Response<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:641:23
    I/GeckoDump( 1811): actorProto/</handler/sendReturn@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:949:26
    I/GeckoDump( 1811): resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:40
    I/GeckoDump( 1811): Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23
    I/GeckoDump( 1811): this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7

Comment 2

3 years ago
Patrick, Mike, this looks like a recent regression with the inspector (other tools appear to work fine).
Flags: needinfo?(pbrosset)
Flags: needinfo?(mratcliffe)
Oddly, gDevTools seems to be undefined in the NodeActor's _hasEventListeners getter:

  get _hasEventListeners() {
    let parsers = gDevTools.eventParsers;
    for (let [,{hasListeners}] of parsers) {
      if (hasListeners && hasListeners(this.rawNode)) {
        return true;
      }
    }
    return false;
  },

This has been recently introduced in inspector.js (server side) to support event tooltips in the markupview.
Flags: needinfo?(pbrosset)
Discussing about this with Paul, I realized that gDevTools just doesn't exist on b2g.
If it's imported and used in a Front class, it's fine, but if it's imported and used in an Actor class, then gDevTools will be undefined and that will cause errors.

Searching for gDevTools in /toolkit/devtools, here's what I found:

- Obviously used in event-parsers.js, but this file is only imported by client-side code (main.js).
- A couple of gcli commands use it to show the toolbox, but these commands run client-side, fine.
- There's a csscoverage Front class that uses it, but again, Fronts run on the client, so fine.
- Webconsole's utils.js seems to import it but doesn't use it ... could be removed.
- And finally, inspector.js uses it in a few places:
  - in _hasEventListeners and getEventListeners which is the reason for this bug
  - and in getImageDataFromURL to check for gDevTools.testing, but that could probably be changed easily by passing that flag via the protocol, as a request param.
gDevTools.eventParsers has been introduced as a way for extension authors to customize the way event listeners are parsed/displayed in the markup-view. Parsers actually run on the server-side, within the NodeActor, so gDevTools isn't the right place to define them.

gDevTools was chosen as our main customization entry point, but for anything that runs on the server, this is just wrong because either gDevTools isn't available (on b2g), or it's not the same (when remotely debugging firefox desktop).

We either need a server-side customization entry point, or a way to send customization configuration/code via the protocol.
Assignee: nobody → mratcliffe
Flags: needinfo?(mratcliffe)
Created attachment 8481245 [details] [diff] [review]
event-emitter-b2g-fix-1060188.patch

We really need to cover this kind of situation in our test suite.

Paul, can you give this a try? I have just moved the eventListener stuff into it's own module.

If it works we should land it quickly.

Try:
https://tbpl.mozilla.org/?tree=Try&rev=2d85b6baea2a
Attachment #8481245 - Flags: review?(paul)
Created attachment 8481255 [details] [diff] [review]
event-emitter-b2g-fix-1060188.patch

In fact, let's not break the registering of new event parsers.

Try v2:
https://tbpl.mozilla.org/?tree=Try&rev=3db18d05606f
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=3db18d05606f
Attachment #8481245 - Attachment is obsolete: true
Attachment #8481245 - Flags: review?(paul)
Attachment #8481255 - Flags: review?(paul)
We really do need a remote entry point so I have logged Bug 1060383 - Add an extension entry point for server-side code.
Comment on attachment 8481255 [details] [diff] [review]
event-emitter-b2g-fix-1060188.patch

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

Stealing from Paul.  Looks good, thanks for fixing this quickly.

::: toolkit/devtools/server/actors/inspector.js
@@ +369,5 @@
>     *         so far.
>     * @param  {Debugger} dbg
>     *         JSDebugger instance.
>     * @param  {Object} eventInfo
> +   *         See event-parsers.js.registerEventParser() for a description of the

This should probably be "EventParsers.registerEventParser".
Attachment #8481255 - Flags: review?(paul) → review+
Since Try seems good and I am guessing Mike is done working for the week, I am marking this checkin-needed.
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/96fd68f9c83e
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/96fd68f9c83e
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 34

Updated

3 years ago
Duplicate of this bug: 1060794
I couldn't reproduce this using 2014-08-28 Nightly (Mac OS X 10.9.5) and a Flame device with FirefoxOS 1.4 on both App Manager and WebIDE. I believe my Firefox OS version is not the correct one.

Michael, is it working for you now? Thanks!
Yup, I've been using it every day for over a month. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.