Skip to content

Instantly share code, notes, and snippets.

View juliandescottes's full-sized avatar

Julian Descottes juliandescottes

View GitHub Profile
async onAnimationsMutation(changes) {
if (!this.isPanelVisible()) {
return;
}
// ...
}
async onTargetAvailable({ isTopLevel, targetFront }) {
if (isTopLevel) {
this.animationsFront = await targetFront.getFront("animations");
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.41 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/tmpVkRt3F.mozrunner'; const _SERVER_PORT = '8888'; const _SERVER_ADDR = '127.0.0.1
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
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
# HG changeset patch
# User Julian Descottes <jdescottes@mozilla.com>
# 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

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.

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.

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
/* 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");

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: