open extension devtools API's proof of concept

[Luca Greco]

Hi all,

as part of my diving inside the WebExtension internals I've started to look
into "what we need to implement to introduce the devtools API":

- https://bugzilla.mozilla.org/show_bug.cgi?id=1211859

It is definitely far from being complete or mergeable, but I think that it
could be a good starting point for a discussion about what is missing or
the issues I've found and their proposed workarounds, and get new
proposals, ideas and solutions.

In the above bugzilla issue I've already attached the proof of concept
patch (and a related testcase), a sketched diagram of the components
involved and an initial list of notes I've collected (issues, workarounds
and not yet implemented features).

Currently I asked a preliminary feedback on the patch (to Bill McCloskey)
about the WebExtension part of the patch, but I definitely need a
preliminary feedback from the DevTools team too (e.g. there is a small
actor in the current patch, but there is nothing definitive and I'd really
like to discuss any alternative approach that you can think about)

During the bootstrap of this experiment I've used a real chrome devtools
addon to be sure that I was not creating a "fiction" version of the real
API:

- BackboneDebugger (https://github.com/Maluen/Backbone-Debugger)

I'm going to push my changes to above addon in my fork on github asap (they
are just small changes about differences that it doesn't make sense to fix
inside firefox, e.g. deprecated chrome.extensions APIs which are now
exposed in chrome.runtime instead) and then I will link its xpi to the
bugzilla issue as an example.

In the mean time here is a screencast of the Backbone Debugger running on
Firefox:

-
https://gist.githubusercontent.com/rpl/8626f7231c9e23f4e478/raw/9132cf4fffa6f5a7ccf5183856cbcb65d35cae6e/BackboneDebugger_running_on_FirefoxWebExtensionAPI.gif

Best,
Luca

--
Luca Greco @ Alca Società Cooperativa
http://github.com/rpl

[James Long]

I've been wanting for us to have something like this for a long time! An
official, clean way to extend tools. Great work.

Personally I would find it useful if a couple of us wrote down requirements
first before fleshing this out too much. There's a lot of semi-complex
things we might want to expose, for example a way of "installing" a custom
backend actor. I don't see a whole lot in your patch except a few simple
APIs, unless I'm missing something?

As we write more stuff in React, there's also a lot of potential for the
ability to completely swap out random React components, like the
pretty-printer or something like that.

Whatever we do, the APIs should be easy to add more complex over time.

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Luca Greco]

On Tue, Oct 6, 2015 at 10:33 PM, James Long <jl...@mozilla.com> wrote:

> I've been wanting for us to have something like this for a long time! An
> official, clean way to extend tools. Great work.
>

Thanks James, I'm always happy when I'm able to turn my contribution time
into something actually useful.

> Personally I would find it useful if a couple of us wrote down
> requirements first before fleshing this out too much. There's a lot of
> semi-complex things we might want to expose, for example a way of
> "installing" a custom backend actor. I don't see a whole lot in your patch
> except a few simple APIs, unless I'm missing something?
>

This is a perfect timing to write down requirements and/or followups, my
goal is currently in the "chrome parity" direction, nevertheless the chrome
devtools api is pretty limited and most of the Firefox addons that I'm
working on with Jan under the FirebugWG github organization do not fall
exactly into the limited chrome devtools API "basket", so my real interest
is open up the WebExtension APIs to more things.

and yes: in the current patch I've just "sketched" the thing (in the
comment I've linked the json files which describe the full chrome devtools
API and I've listed what I didn't looked into yet, e.g. sidebars,
evaluating in a frame or the devtools.network etc.), just the amount needed
to be able to run a real world addon (because I wanted to be sure I was
implementing a reasonable amount of the original API but at the same time I
didn't want to annoy the reviewer by asking a preliminary feedback on a
huge patch)

> As we write more stuff in React, there's also a lot of potential for the
> ability to completely swap out random React components, like the
> pretty-printer or something like that.
>
> Whatever we do, the APIs should be easy to add more complex over time.
>

I absolutely agree, as an example some of the things that we do in most of
the addons in the "github.com/firebug" organization are:

- registering a custom actor into the remote debugging server
- creating custom web-like contexts for the addons UI (where the React code
runs) and injection of custom API into it

and the latter is very similar to define new "ExtensionPage" types in the
WebExtension internals (e.g. in the patch I define two new ExtensionPage
types: devtools_page and devtools_panel) and registering new custom API.

[Alexandre poirot]

2015-10-07 18:17 GMT+02:00 Luca Greco <luca....@alcacoop.it>:

> On Tue, Oct 6, 2015 at 10:33 PM, James Long <jl...@mozilla.com> wrote:
> > Personally I would find it useful if a couple of us wrote down
> > requirements first before fleshing this out too much. There's a lot of
> > semi-complex things we might want to expose, for example a way of
> > "installing" a custom backend actor. I don't see a whole lot in your
> patch
> > except a few simple APIs, unless I'm missing something?
> >
>
> This is a perfect timing to write down requirements and/or followups, my
> goal is currently in the "chrome parity" direction,

+1 about focusing on parity first!!
No questions to answer. Just many patches and tests to write ;)
I would suggest landing by steps, it doesn't sound reasonable to land the
whole devtools API at once.

I'm not sure exposing raw actors is suitable for web extensions.
This is a significative API to introduce by itself, isn't webby at all and
can be subject to discussion.
But I don't want such discussion/comment to slow down your progress on this
patch and simple parity!