juliandescottes

console.error: "VariableReference@resource://gre/modules/Fluent.jsm:325:9
resolveExpression@resource://gre/modules/Fluent.jsm:283:14
resolveComplexPattern@resource://gre/modules/Fluent.jsm:443:18
formatPattern@resource://gre/modules/Fluent.jsm:700:19
getString@resource://devtools/client/shared/vendor/fluent-react.js:67:25
getString@resource://devtools/client/shared/vendor/fluent-react.js:231:21
getString@resource://devtools/client/shared/vendor/fluent-react.js:239:44
updateTitle@resource://devtools/client/aboutdebugging-new/src/components/App.js:64:11
componentDidUpdate@resource://devtools/client/aboutdebugging-new/src/components/App.js:56:10
commitLifeCycles@resource://devtools/client/shared/vendor/react-dom.js:12958:22

juliandescottes

DebuggerServer setupInChild is one of the methods relying on message manager. 
I was trying to track down the current usage for this method, it seems only used in tests?

setupInChild usage:
- registerActor and unregisterActor in devtools/server/actors/utils/actor-registry-utils.js

actor-registry-utils usage:
- imported by actor-registry.js (actor)
- used in ActorActor::unregister and ActorRegistryActor::registerActor

juliandescottes

API consistency between Front and TargetList

Fronts have onFront(type, callback), offFront(type, callback). The TargetList has listen(type, createCallback, destroyCallback) and unlisten(type, createCallback, destroyCallback).

The two APIs seem to care about similar lifecycles, so it would be great if the API had a similar shape. Having a single method with 2 callbacks means all consumers need to attach their listeners for creation and destruction at the same spot. It might not be flexible enough in all situations?

Proposal 1:

juliandescottes

/* Any copyright is dedicated to the Public Domain.
   http://creativecommons.org/publicdomain/zero/1.0/ */

"use strict";

// Test the TargetList API

const { DebuggerClient } = require("devtools/shared/client/debugger-client");
const { DebuggerServer } = require("devtools/server/debugger-server");

juliandescottes

diff --git a/devtools/client/framework/ToolboxProcess.jsm b/devtools/client/framework/ToolboxProcess.jsm
--- a/devtools/client/framework/ToolboxProcess.jsm
+++ b/devtools/client/framework/ToolboxProcess.jsm
@@ -135,17 +135,17 @@ BrowserToolboxProcess.prototype = {
     dumpn("Initializing the chrome toolbox server.");
 
     // Create a separate loader instance, so that we can be sure to receive a
     // separate instance of the DebuggingServer from the rest of the devtools.
     // This allows us to safely use the tools against even the actors and
     // DebuggingServer itself, especially since we can mark this loader as

juliandescottes

Debugging the Browser Toolbox

This documentation is about debugging the Browser Toolbox or Omniscient Browser Toolbox.

Debugging the UI

If you need to debug the client side of the Browser Toolbox, you can simply open another Browser Toolbox from your current Browser Toolbox. Make sure "Enable Remote Debugging" is checked in the DevTools setting of the Browser Toolbox, and then use the regular Browser Toolbox shortcut. It will open another Browser Toolbox (running in yet another Firefox instance).

Let's call this the Browser Toolbox Toolbox.

juliandescottes

DevTools Server Architecture and JsWindowActors

I realize it is hard/impossible to follow the discussions around the JsWindowActor work that is currently ongoing in DevTools. I think a small overview of the DevTools architecture before and after will help.

First of all a warning, I am going to mostly talk about the "easy" scenario, where you have one toolbox that debugs one tab. Things can get really complicated if you start mixing local toolboxes and remote toolboxes, plus a few exotic clients such as aboutdebugging. If things seem overly complicated for no reason, it's probably because of one of those scenarios (although it's always good to challenge it!)

Simple DevTools Architecture

Let's start with the current state.

juliandescottes

# HG changeset patch
# User Julian Descottes <[email protected]>
# Date 1574272514 -3600
#      Wed Nov 20 18:55:14 2019 +0100
# Node ID d6dbb549fa57a45a4fba92ce6ce1e6e36d34d163
# Parent  7c17c8c8997ba0811bcd57dc8552da5a5275afec
Add fission mochitest

diff --git a/devtools/client/framework/moz.build b/devtools/client/framework/moz.build
--- a/devtools/client/framework/moz.build

juliandescottes

import os, re

devtools_root = os.path.abspath(".");
print devtools_root, ": DEVTOOLS ROOT\n"

def path_repl(matchobj):
    print "REPL MATCHOBJ", matchobj.group(1)

    fullpath = os.path.join(current_root, matchobj.group(1))
    print "REPL FULLPATH", fullpath

juliandescottes

jdescottes@juliandescottes-0klvdr:~/Development/hg/fx-team-artifact$ mt /Users/jdescottes/Development/hg/fx-team-artifact/devtools/client/webconsole/test/browser/_webconsole.ini
 0:00.39 INFO Checking for ssltunnel processes...
 0:00.40 INFO Checking for xpcshell processes...
 0:00.42 SUITE_START: mochitest-browser - running 2 tests
 0:00.42 INFO Running manifest: devtools/client/webconsole/test/browser/_webconsole.ini
pk12util: PKCS12 IMPORT SUCCESSFUL
 0:00.83 INFO Increasing default timeout to 90 seconds
 0:00.83 INFO MochitestServer : launching [u'/Users/jdescottes/Development/hg/fx-team-artifact/objdir.noindex/dist/bin/xpcshell', '-g', u'/Users/jdescottes/Development/hg/fx-team-artifact/objdir.noindex/dist/NightlyDebug.app/Contents/Resources', '-f', u'/Users/jdescottes/Development/hg/fx-team-artifact/objdir.noindex/dist/bin/components/httpd.js', '-e', "const _PROFILE_PATH = '/var/folders/gg/3djmyw1514zdnv65k6tn9tgh0000gn/T/tmpI7mPCb.mozrunner'; const _SERVER_PORT = '8888'; const _SERVER_ADDR = '127.0.0.1