The web console has a number of formatters for various value types that are currently not being used. This results in [] appearing as [object Array] instead of Array [ ].

The layout-view expects a autoMargins property in the response object when it calls styles.getLayout.
Right now, our ChromiumPageStyleActor.getLayout implementation returns an empty object for autoMargins.

The object is supposed to be something like {top: "auto", right: "auto"}, depending on which margins have been set to auto.

Once stylesheets have been listed in the style-editor panel, navigating to a new page doesn't seem to refresh that list.

1. Connect to Safari on iOS
2. Press device's Home button, on console:
   JPM info console.log: fxdevtools_adapters: <<<<<< Sent to device
   {"id":14,"method":"Page.disable","params":{}}

The device is no longer connected although it appear as it is (Safari tab remains in view), the Disconnect button is disabled. It still cannot be used after returning to Safari after pressing the device's Home button.

If Safari is closed on device, the opened tab disappears from project view and the Disconnect button is unavailable.

Evaluating a non-existing identifier in the console results in the following error:

TypeError: handle is undefined
Stack:
exports.gripType<.write@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/9c214bf5-37ff-4521-b990-442dd6041ef7/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/value.js:47:9
types.addDictType/<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:216:23
RetVal<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:490:12
Response<.write/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:643:1
Response<.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:641:23
actorProto/</handler/sendReturn@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:949:26
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:40
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7

In the debugger, when you set a breakpoint on a more complex page, sometimes when it hits the breakpoint it errors out with an error about frameThis in FrameActor being null. Looking into it.

Opening a new tab in Safari (iOS 8.1) doesn't update WebIDE's current app/project (there is nothing shown here). The device still appears as connected and the Disconnect button is not available.

Console:
JPM info console.log: fxdevtools_adapters: <<<<<< Sent to device
{"id":220,"method":"DOM.hideHighlight","params":{}}

With Safari on OSX, I can debug WebViews embedded in native apps.
However, with the adapter running on linux, I can only debug safari itself. It will not accept connections when a native app with a WebView is open.

It would be nice to also support this, if the platform limitations allow this.

The pretty-printing & blackboxing doesn't work right now and we probably won't get it working, and we talked about hiding the buttons. Not sure how hard this will be. It will require a patch to Firefox that needs to be uplifted to Aurora so I'll look into it now so we have a chance of getting it landed.

(I'll open a bug in bugzilla instead once this gets more serious)

Looks like we don't get doctypes right.

Which is probably because of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=917696

At least on ios (haven't tested on chrome).
I can see the list of scripts and set breakpoints, only these breakpoints never pause execution.

This was added recently to the FirefoxDevTools and is based on a new SelectorHighlighter in the back-end that retrieves all nodes that match a given selector and highlights them all.

Probably not the first thing to work on in the inspector, especially that there's a trait on the root actor that tells the front-end if this special highlighter exists or not, so it doesn't break if it's not here.
But if chromium's DOM.highlightNode request allows several nodes to be highlighted at the same time, this would be fairly easy to implement.

We should investigate whether it's possible to just call CSS.getMatchedStylesForNode once in ChromiumPageStyleActor.getApplied() (or rather in addElementRules()) instead of once for the element and once for each of its ancestors.
Indeed, CSS.getMatchedStylesForNode supports a inherited flag that seems like it should do the trick.

After PR #108 lands, we should take advantage of the ios protocol's displayName and inferredName properties sent as part of the FunctionDetails response to make the console output preview for functions better.

I thought I would be able to fix this quickly, but the reason why this doesn't work eludes me for now, so I'm creating an issue for it.

• When clicking on the "pick" icon, this sends a request to our highlighter actor which then sends a DOM.setInspectModeEnabled request via the ios protocol
• As specified in the protocol descriptor, this is supposed to then emit a Inspector.inspect event when an element is selected from the page.

So, we have 2 problems:

• the code in walker.js for now only listens to DOM.inspectNodeRequested, so we need to make it also listen to Inspector.inspect,
• even when done, nothing happens when selecting an element in the page.

What's weird is that using the ios webkit proxy with the google chrome devtools, I can sort of see that the Inspector.inspect event is indeed sent in the debug output, but in our case, nothing gets sent back when selecting an element from the page.

Prerequisites:

• Google Chrome for Android installed from Google Play on a device - open a page
• Android SDK installed on Windows
• USB debugging option enabled on device

Steps to reproduce: Open WebIDE from Developers Tools latest build and select "Chrome on Android" option from "Select runtime" menu

ER: The page opened on device using Chrome can be debugged from WebIDE

AR: The "Chrome on Android" option doesn't appear on WebIDE's menu

We're adding this addon to WebIDE's addon manager, where the user might disable the addon. We need to unregister properly the runtimes.

If you click on the debugger and switch to another tool you'll see that the debugger tab is green meaning that it's paused. The UI doesn't show any reason is should be paused. For some reason it always loads up paused. Pressing the button to resume doesn't seem to do anything.

EDIT: ok, I'm starting to get the hang of this. This only happens in Chrome, works fine in iOS.

The rule-view is supposed to differentiate between matched and unmatched selectors in the comma separated list of selectors for each rule. This isn't the case here.

We'll want to have a static build of ios_webkit_debug_proxy for each of the platforms it runs on inside this addon.

@paulrouget, is this something you could take a look at?

How would I need to implement a runtime adapter such as

https://github.com/campd/fxdt-adapters/blob/ab3000170477a56fb74640935a9eab230560ac0b/lib/main.js#L72-L87

in order to forward the remote debug JSON protocol to a NodeJS server? Is there a prototype example somewhere?

Haven't done much research, but getting the source of the HTML page is wrong, you get a random script it seems (seems to vary depending on timing, it's weird). It should be pretty easy to do what we do now for Firefox and just re-fetch the HTML.

Filing this away for the future, I don't have time to look into it right now, but if you load up a page with something like this:

function foo() {
  throw new Error(5);
}

foo()

The error isn't shown anywhere if you are connected and reload the page. It should show up in the console.

I haven't been able to debug Chrome Canary anymore for a few days now.
Version is 40.0.2203.3 canary (64-bit).
Debugging Chrome release does work though. Version is 38.0.2125.111.

I get the following error message when trying to connect:

And in the logs:

JPM info console.log: fxdevtools_adapters: <<<<<< Connecting to ws://localhost:9222/devtools/page/B47ACBC3-2A4A-40F1-8FD1-6D8B2E0EE8F8...

JPM info console.log: fxdevtools_adapters: >>>>>> Connection established

JPM info console.log: fxdevtools_adapters: <<<<<< Sent to device
{"id":1,"method":"Inspector.enable","params":{}}

JPM info console.log: fxdevtools_adapters: >>>>>> Received from device
{"id":1,"result":{}}

JPM info console.log: fxdevtools_adapters: <<<<<< Sent to device
{"id":2,"method":"Page.getResourceTree","params":{}}

JPM info console.log: fxdevtools_adapters: >>>>>> Received from device
{"id":2,"result":{"frameTree":{"frame":{"id":"869.1","loaderId":"869.2","url":"https://www.google.fr/search?q=test&oq=test&aqs=chrome.0.0l6.443j0j7&sourceid=chrome&es_sm=91&ie=UTF-8","mimeType":"text/html","securityOrigin":"https://www.google.fr"},"resources":[{"url":"https://ssl.gstatic.com/gb/images/i1_71651352.png","type":"Image","mimeType":"image/png"},{"url":"https://www.google.fr/gen_204?v=3&s=web&imc=1&imn=1&imp=0&ei=pu9RVJuzDJLbaojkgYgF&e=3700318,4005878,4016824,4017981,4018673,4019182,4019511,4020347,4020562,4020666,4020873,4020921,4021162,4021364,4021587,4021597,4021775,4022495,4022574,4022756,4023083,4023373,4023979,4024410,4024660,8500271,8500325,8500393,8500700,10200083,10200716&atyp=csi&adh=&xjs=init.69.30.sb.45.p.9.m.3.spch.2.dvl.2&action=&srt=314&p=s&npn=1&rt=xjsls.202,prt.203,xjses.278,xjsee.390,xjs.406,ol.456,iml.203,wsrt.305,cst.0,dnst.0,rqst.353,rspt.243","type":"Image","mimeType":"text/html"},{"url":"data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw%3D%3D","type":"Image","mimeType":"image/gif"},{"url":"https://www.google.fr/images/nav_logo195.png","type":"Image","mimeType":"image/png"},{"url":"data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5BAEAAAcALAAAAAAcACYAAAO9eLpMIMYIQJi9DcYtKv6KtnHgB4yoAZSXKAyDy1rjoAzjzOQLrx8+4OanCAZnxiExGSEKmz3lj2lwUq3SZ3WZPbKuXGgxu9t4tLYDTkpIRQILF0x2G4lWipM7gj/oJQUkcXsCDCIFATULBCIcZ2tvB3QLDxETFnR/BgU/gRt9jX0gnpYMkJZpFzEoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=","type":"Image","mimeType":"image/gif"},{"url":"https://www.google.com/textinputassistant/tia.png","type":"Image","mimeType":"image/png"}]}}}

JPM info console.log: fxdevtools_adapters: <<<<<< Sent to device
{"id":3,"method":"Page.enable","params":{}}

JPM info console.log: fxdevtools_adapters: >>>>>> Received from device
{"id":3,"result":{}}

JPM info console.log: fxdevtools_adapters: <<<<<< Sent to device
{"id":4,"method":"CSS.enable","params":{}}

JPM info console.log: fxdevtools_adapters: >>>>>> Received from device
{"error":{"code":-32000,"message":"DOM agent needs to be enabled first."},"id":4}

The toolbar icon is convenient for working on this add-on, but I am not sure we need it for real use, since we can expose the same actions through WebIDE, which seems more consistent since that's how you get to the other runtimes. Thoughts? We could potentially keep it just for add-on development, but remove it from the release build.

Naturally, I would not hide it until we're actually exposing the same functionality in the runtime list (it's not clearly labelled that way at the moment).

Using the resource-store class, it should be feasible to get the content for a given image URL so that we can implement NodeActor.getImageData (marked TODO so far).
This will make markup-view image preview tooltips work.

Tested here: http://jsbin.com/sorakeloxaku/1/edit
STR:

• Click on the element picker icon
• Select the test element in the right hand side iframe

JPM error Message: TypeError: node is undefined
Stack:
ChromiumWalkerActor<.ensurePathToRoot@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///var/folders/17/384y6ycd72n0_fpjwwcl01y80000gn/T/a4197725-2641-4d1d-b939-02c33f221391/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/walker.js:766:9
ChromiumWalkerActor<.onInspectNodeRequested@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///var/folders/17/384y6ycd72n0_fpjwwcl01y80000gn/T/a4197725-2641-4d1d-b939-02c33f221391/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/walker.js:457:23
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:96:9
TabConnection<.onMessage@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///var/folders/17/384y6ycd72n0_fpjwwcl01y80000gn/T/a4197725-2641-4d1d-b939-02c33f221391/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/rpc.js:56:7

Also, trying to access the iframe just by expanding nodes in the markup-view shows that its a childless node that can't be expanded.

My lame guess is some server-side code isn't cleaned up on unload - the workaround is just to re-start nightly.

I see this error:

JPM info console.error: fxdevtools_adapters:

JPM error Message: Error: Type 'chromium_grip' already exists.
Stack:
types.addType@resource://gre/modules/devtools/server/protocol.js:142:1
@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/value.js:25:20
@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/webconsole.js:8:16
@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/root.js:15:32
@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/server.js:15:29
@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:11:16
run@resource://gre/modules/commonjs/sdk/addon/runner.js:145:19
startup/</<@resource://gre/modules/commonjs/sdk/addon/runner.js:86:7
Handler.prototype.process@resource://gre/modules/Promise-backend.js:865:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise-backend.js:744:7

STR:

• Follow instructions here to open up a toolbox against a remote browser https://github.com/campd/fxdt-adapters#debugging-chrome-on-desktop
• Everything opens up and works (I can select elements, change styles, etc)
• Navigate to a different page in the remote browser

Expected:
Things still work

Actual:
The inspector turns white, and I see errors like this in the browser console:

TypeError: node is null
Stack trace:
ChromiumWalkerActor<.children<@resource://gre/modules/addons/XPIProvider.jsm -> file:///Users/bgrinstead/Library/Application%20Support/Firefox/Profiles/pww9ccdu.dev/extensions/[email protected]/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/walker.js:684:9
TaskImpl_run@resource://gre/modules/Task.jsm:314:40
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
actorProto/</handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:941:19
Connection<.onPacket<@resource://gre/modules/addons/XPIProvider.jsm -> file:///Users/bgrinstead/Library/Application%20Support/Firefox/Profiles/pww9ccdu.dev/extensions/[email protected]/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/server.js:50:7
TaskImpl_run@resource://gre/modules/Task.jsm:314:40
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/transport/transport.js:545:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
 protocol.js:852
"SEND: {
  "from": "chromium2.chromium_domwalker11",
  "error": "unknownError",
  "message": "TypeError: node is null"
}" server.js:33
"Protocol error (unknownError): TypeError: node is null" protocol.js:16
"Protocol error (unknownError): TypeError: node is null" deprecated-sync-thenables.js:48

This happens in the debugger panel.
It looks like chromium doesn't provide the whole text content for scripts that are inside HTML documents. It only returns the script itself. And our front-end probably expects HTML so tries to highlight it as such.

If Chrome Desktop is unreachable (not running, etc.), the runtime should throw, so that WebIDE can present a reasonable error message.

Right-click in the rule-view, select add rule. This works on Chrome, but not on ios.

On the surface, this should be pretty easy with https://developer.chrome.com/devtools/docs/protocol/1.1/timeline.
Then of course, we need to be able to map Chrome's terminology to ours.
I'm taking a look at this now.

We're starting to publish videos and docs and such with the name "Valence" now.

We should at least rename the add-on. We could also rename the repo too.

WebIDE would need a string change as well to update it's pre-install name for the add-on.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1088616
This bug describes how the computed-view gets a list of all supported properties on the toolbox side.
Because of this, there are certain properties that webkit doesn't support that the computed-view will try to access and this will fail.

It looks like applied rules are ordered by least specificificity in the rule-view.

Used fxdt-adapters with latest merge: "Merge pull request #80 from jlongster/master"

1. Opened Google Chrome and entered two different websites in two tabs
2. Connected to Chrome from WebIDE
3. Selected one tab and opened the Inspector for it - Inspector looks good
4. Selected the other tab - the Inspector was already open
5. Switched to the first tab - Inspector was black
6. Returned to the second tab - Inspector contained no data

This doesn't occur with Debugger tab

We should move this to the main Mozilla GitHub org now that it's more official.

@paulrouget said we should be careful to remove this repo though, or else all the PRs will go to @campd or something.

Given:

 let iOSRuntime = {
    getName: function() {
      return "iOS proxy";
    },
    connect: function(connection) {
      let transport = server.connect("http://localhost:9222");
      connection.connect(transport);
      return promise.resolve();
    },
  }
  AppManager.runtimeList.custom.push(iOSRuntime);

What API interface is transport expected to have for use in connection.connect(transport)?

I am trying to figure out where this fits in the Debugger / RDP / Debug server/client picture.

I am trying to write a debug server (assuming the devtools debugger UI is the client?) I can run in an extension to simulate a debuggable runtime.

That's because the rule-view actually checks for properties validity on the client-side, therefore in a gecko browser. The actor doesn't tell it when a property is invalid.

See this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1069829 as this requires changes in the devtools.

I used Nightly 36.0a1 2014-10-27:

• Style Editor loads forever when opening chrome://newtab for the first time
• The name of the debugging window remains chrome://newtab even after opening other pages in the same tab or in other tabs
• The content on Inspector tab turns white after some time, see http://i.imgur.com/csR4wse.jpg; modified rules are still applied
• After inspecting some pages, the console is not refreshed any more, it has to be closed and reopened

I get this error in the console when firing up WebIDE and selecting "iOS proxy". I don't have any apps installed and haven't used WebIDE before, so that might be related. The error seems harmless and I can use fever dream fine.

JPM info Handler function DebuggerClient.requester request callback threw an exception: Error: 'getAll' request packet has no destination.
Stack: DebuggerClient.prototype.request@resource://gre/modules/devtools/dbg-client.jsm:667:1
AppActorFront.prototype.watchApps@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/app-actor-front.js:570:35
AppManager.onConnectionChanged/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/webide/app-manager.js:139:9
DebuggerClient.requester/</<@resource://gre/modules/devtools/dbg-client.jsm:348:9
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
emit@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///var/folders/kx/1gnshz117g378t2d7kwqg9_c0000gn/T/20e9725b-17f3-449e-b9a3-36579d7fe67e/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:96:9
Request.prototype.emit@resource://gre/modules/devtools/dbg-client.jsm:1092:29
DebuggerClient.prototype.onPacket/<@resource://gre/modules/devtools/dbg-client.jsm:931:9
resolve@resource://gre/modules/devtools/deprecated-sync-thenables.js:40:40
then@resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
then@resource://gre/modules/devtools/deprecated-sync-thenables.js:58:9
DebuggerClient.prototype.onPacket@resource://gre/modules/devtools/dbg-client.jsm:869:1
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/transport/transport.js:545:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
Line: 667, column: 0

So far I've only brushed the surface of the addon by fixing a few inspector-related bugs, but I feel like I'm missing a lot of information when it comes to how the addon actually works.
Here are some of the questions I have in mind:

• why are actors prefixed with chromium_ knowing that we support both blink and webkit-based browsers for now. Is this just a naming thing?
• What happens when/if we want to support other browsers with completely different protocols? Where would the code to switch from one implementation to the other be?
• How do we deal with differences between ios and chrome protocols? So far, I've been confronted with this only a couple of times, and it was easily solved with an if (supports this) { ... } else (supports that) { ... }. More importantly, how are we going to deal with new protocol versions?
  I believe answering these questions in the README.md or in the project wiki would not only be beneficial to me but to anyone who's willing to help on the project. That's why I'm filing this issue.
  I'm fine to write that doc, but I need some light on the subject.

It looks like both the ios and chrome protocols do have a DOM.getEventListenersForNode command, so we should be able to support some kind of event tooltip in the markup-view.

The response object contains a list of eventlisteners that have the following format:

[
  { "name": "type", "type": "string", "description": "<code>EventListener</code>'s type." },
  { "name": "useCapture", "type": "boolean", "description": "<code>EventListener</code>'s useCapture." },
  { "name": "isAttribute", "type": "boolean", "description": "<code>EventListener</code>'s isAttribute." },
  { "name": "nodeId", "$ref": "NodeId", "description": "Target <code>DOMNode</code> id." },
  { "name": "handlerBody", "type": "string", "description": "Event handler function body." },
  { "name": "location", "$ref": "Debugger.Location", "description": "Handler code location." },
  { "name": "sourceName", "type": "string", "optional": true, "description": "Source script URL." },
  { "name": "handler", "$ref": "Runtime.RemoteObject", "optional": true, "description": "Event handler function value." }
]

See https://github.com/campd/fxdt-adapters/blob/master/lib/chromium/reflow.js#L16
Pull request #89 will make the layout-view on ios, so we should spend more time trying to make the reflow actor fully work on ios too, so that the layout-view refreshes as dimensions change.

One good way to test this is:

• start with the iDevice in landscape mode
• select an element
• switch to the layout-view inspector sidebar panel
• rotate the device to portrait mode

The layout-view should be automatically refreshed to show the new dimensions.

I wrote this JS library to interact with php xdebug and I think its a prime candidate to be ported to this project and made into an adapter: https://github.com/ajaxorg/lib-phpdebug

What do you think? Realistic?

It should be pretty simple to get Scratchpad to work, since it's using the web console actor, but I get the following error when trying to evaluate or run anything in Scratchpad:

A coding exception was thrown in a Promise resolution callback.
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

JPM info Full message: TypeError: aError is undefined
Full stack: SP_writeAsErrorComment@chrome://browser/content/devtools/scratchpad.js:924:11
SP_display/<@chrome://browser/content/devtools/scratchpad.js:610:9
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7

Some message categories are not received by the webconsole actor, like JS and CSS errors.

There's no equivalent of our ReflowActor on the server, so the box model tab doesn't update when the selected node's box model changes.