987649 - devtools addon fails to inspect DOM

Status: RESOLVED INVALID

(DevTools :: General, defect)

Description

[Axel Hecht [:Pike]]

The fix in bug 971177 didn't fix the actor problem I have, so filing a new bug.

I have a devtools addon that tries to inspect the (eventually remote) DOM and CSS.

I'm just using Nightly against Nightly right now, my add-on is based on Victor's restartless template and I published my code at https://github.com/Pike/mock-l10n/tree/devtools-actor.

I end up with

Error: Unexpected packet conn2.stylesheets786, {"styleSheets":[],"from":"conn2.stylesheets786"}
Stack-Trace:
Front<.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1059:1
DebuggerClient.prototype.onPacket/<@resource://gre/modules/devtools/dbg-client.jsm:689:9
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:118:11
then@resource://gre/modules/commonjs/sdk/core/promise.js:43:43
then@resource://gre/modules/commonjs/sdk/core/promise.js:153:9
DebuggerClient.prototype.onPacket@resource://gre/modules/devtools/dbg-client.jsm:731:1
LDT_send/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/server/transport.js:258:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:80:7

This is about:blank, opening the devtools, MockL10n tab, hitting the "Localize" button. The error shows up in the browser console.

Comment 1

[Axel Hecht [:Pike]]

Attachment: test case, run twice

Paul helped me to create a reduced test case.

Heather, if you paste this into a chrome scratchpad, the first time it'll succeed, but fail the second time, 'cause connections don't match up.

Paul had hit this before, and worked around it at http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/device.js#225, but that'd be sad to do all over, I guess?

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

We could also go the other direction and make this front deduplication (like the device snippet you referenced) a regular feature of all protocol.js fronts (assuming that resolves this issue to start with...).

It seems unusual to desire a unique front for the same target, so it makes sense to track them in this way.

Comment 3

[Patrick Brosset <:pbro>]

These types of add-ons no don't work anymore with Quantum. Let's close this bug.