Devtools Widget Unity

[Jordan Santell]

We have a range of widgets with overlapping/duplicated functionality, some
rotting with no updates, and many fixes/polish for tools are in these
widgets themselves. To have a cohesive widget story that’s shared across
our tools would be a solid win, ideally sharing features across tools for
free (imagine if all of our table views were instantly sortable/resizable!).

Some potential goals this endeavor would achieve are:
* Remove/reduce neglected current widgets
* Share widget features across tools
* Any refactoring/new widgets have an opportunity to kill XUL in a component
* New components we do not have and need (resizable/sortable table, only
render in view list)
* Take advantage of React/redux combo on tools that use it for differential
rendering

There are a few ways we could go about this — based on an audit of our
widgets, most of the duplicated code revolve around tree, lists and tables.
Lists can be thought of as a subset of trees, whereas adding table
functionality can extend either. Whether or not these all should extend
from the same core widget, not sure. To go about this process, we should
make/choose a widget that solves the issues, and begin wiring it up to
current tools, dropping depreciation messages in current widgets, and
ultimately remove them. We have a lot of cruft here.

At the bottom is an audit of implementations and consumers for each of the
types (tree, list, table). This was spawned from a discussion[0] about
adding sortable/resizable columns in the performance call tree, which isn’t
possible because it’s not really a table. In terms of tree-table
requirements based on our current bugs across several tools, the following
would achieve what we need:

* Only render visible items
* Custom line items for each consumer of widget
* Tree capabilities (expand/collapsible)
* Table capabilities (sortable, resizable, reorderable?)

For the tree implementation, the one that seems the most complete in all
the functionality above, except table capabilities, fitzgen’s Tree in the
initial memory tool prototype from years ago[1]. If we can identify a
robust/flexible way to implement a table-tree widget, it would handle the
table widget problem (all top level tree items), as well as the list widget
(all top level tree items, single “column”), and a normal tree widget
(single “column”).

If this sounds good and like something we want to tackle in the future,
let’s talk about how we’re going to do just that, and I’ll make some bugs.
I love making bugs.

*Widget Audit - List Widgets (4 implementations, 5 current consumers)*
* webconsole (custom)
* Netmonitor (custom)
* FastListWidget
* Vestigial includes in Debugger (can be removed)
* SimpleListWidget
* Debugger (global search, watch expressions, results panel)

*Widget Audit - Tree Widgets (5 implementations, 14 current consumers)*
* Abstract Tree Widget
* Performance (call tree/allocations, waterfall)
* TreeWidget
* storage, jit optimizations
* VariablesView
* Webconsole, web audio, storage, scratchpad, tooltips?, netmonitor,
debugger, webide (manifest)
* JSONResponseViewer Tree?[2]
* Heap Tree View (fitzgen’s patch on memory tool prototype)[1]

*Widget Audit - Table Widgets (1 implementation, 2 consumers)*
* Table Widget
* storage, webconsole (console.table?)

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1201742
[1]
https://bugzilla.mozilla.org/attachment.cgi?id=8487436&action=diff#a/browser/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1132203

--
Jordan Santell
Sr. Software Engineer | DevTools Performance & Memory

[James Long]

Definitely interested in helping, Jordan. No surprise, but I think React
will help not only for optimizing the rendering, but also can provide a
really clean & composable interface. It's also super easy to integrate
w/existing stuff (if we wrote React stuff, non-React tools could just use
`React.render(component, ...)` to mount them.

I don't have the time right now to propose anything in detail though and
I'm sure we'll talk about this more. Let me know if you want some help from
me and want to see how React might play into this.

On Mon, Oct 12, 2015 at 12:32 PM, Jordan Santell <jsan...@mozilla.com>
wrote:

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

[Jan Odvarko]

I am also very interested in this. I’ve got some experience
when doing tree-view for the JSON Viewer as well as for
some of the existing extensions for devtools (FireQuery, RDPi,
WebSocket Monitor, etc.) all using ReactJS
I think that it would be great to arrange a meeting!

Honza

[Alexandre poirot]

In my quest to unify toolbox UI across tool, this proposal looks very
promising!

But it looks like you are not focusing on the same widget than me?
What about the resource list in Debugger and Style Editor? Are they both
custom?
I'd be interested in helping about these particular widgets.

(In my Whistler prototype, I demoed a HTML, React based ressource tree,
with search)

[Dylan Barrell]

Making this turducken tree-list-table widget accessible will be
difficult you would at the very least have to choose the treegrid
markup http://www.w3.org/TR/wai-aria/roles#treegrid or otherwise
implement different markup depending on whether the widget is playing
the role of a list, a tree, a grid or a tree grid.

I am not sure that is better than just implementing simple re-usable
components for each of these

--Dylan

[Patrick Brosset]

There are also smaller, albeit important, widgets like the preview of a DOM
Node. Apart from the markup-view (where it's much more than just a preview
because it's also editable, draggable, ...) it's used also in the web
console output, in the variables view, as well as in the
animation-inspector. Very little is shared between these implementations.

The breadcrumbs widget also comes to mind, it's used in the inspector and
in the debugger (when paused), and we are using 2 distinct implementations.

On Tue, Oct 13, 2015 at 4:11 PM, Alexandre poirot <poiro...@gmail.com>
wrote:

[Nick Fitzgerald]

On Tue, Oct 13, 2015 at 7:11 AM, Alexandre poirot <poiro...@gmail.com>
wrote:

> What about the resource list in Debugger and Style Editor? Are they both
> custom?
> I'd be interested in helping about these particular widgets.
>

​They are both SideMenuWidget instances, so they are shared atm.

However, James is rewriting the debugger frontend in react/redux​, so this
will change relatively soon, and additionally, we intend to make the
debugger's source list a directory tree style thing. I think it would make
sense to do the same to the style editor.

[Jordan Santell]

Created a metabug[0] for this work, with a few bugs blocking it. Honza,
James and myself are meeting tomorrow to jam out some requirements and
constraints with react components and how to solve scenarios of tools using
Redux, and ones that are not, and a common API between them, so looking
forward to progress.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1214202

On Tue, Oct 13, 2015 at 9:24 AM, Nick Fitzgerald <nfitz...@mozilla.com>
wrote:

[J. Ryan Stinnett]

On Tue, Oct 13, 2015 at 11:24 AM, Nick Fitzgerald

<nfitz...@mozilla.com> wrote:
> On Tue, Oct 13, 2015 at 7:11 AM, Alexandre poirot <poiro...@gmail.com>
> wrote:
>
>> What about the resource list in Debugger and Style Editor? Are they both
>> custom?
>> I'd be interested in helping about these particular widgets.
>>
>
> They are both SideMenuWidget instances, so they are shared atm.
>
> However, James is rewriting the debugger frontend in react/redux, so this
> will change relatively soon, and additionally, we intend to make the
> debugger's source list a directory tree style thing. I think it would make
> sense to do the same to the style editor.

I am glad we're going to improve the source list! Is
https://bugzil.la/987685 the right bug for this work?

Do we think we'd use one of the unified tree widgets proposed here for it?

I've thought about working on this every time I open Browser Toolbox,
though lately I've been waiting for James to finish his debugger work
before attempting anything.

- Ryan

[Nick Fitzgerald]

On Tue, Oct 13, 2015 at 3:12 PM, J. Ryan Stinnett <jry...@gmail.com> wrote:

> I am glad we're going to improve the source list! Is
> https://bugzil.la/987685 the right bug for this work?
>

​Yes, although I think there are might be dupes on file.​ It is an
oft-requested feature.

> Do we think we'd use one of the unified tree widgets proposed here for it?
>

I would hope so, and I really hope we don't end up with yet another
widget... That said, I think it would need to be a react-compatible thing.
Which​ we don't have in m-c yet (although I did implement one a while back,
which Jordan linked).

I guess this means that the Tree[Table]Widget we unify on may need to be a
new widget. <insert that one xkcd link here, yes that one>

[sebastia...@gmail.com]

Old thread, new input. I think there should also be a unified search and filter field component used across the tools.

It's features would include:
- single content search
- multiple content search
- filtering instead of searching
- search/filter options
- search suggestions
- showing number matches
- indication for no matches
- focus shortcut
- clearing the field
- goto line feature

Some of this may already be part of https://bugzilla.mozilla.org/show_bug.cgi?id=1265759.

Though I wanted to ask whether it's worth to another bug (or several) for creating a unified component.

Sebastian

[Karl Dubost]

Le 12 mai 2016 à 16:20, sebastia...@gmail.com a écrit :
> Old thread, new input. I think there should also be a unified search and filter field component used across the tools.

YES! As a first step before a unified search, at least a convergence.

The debugger has a good search tool
http://imgur.com/e3QtzFo

In CSS
! == search in multiple files
@ == search in Selectors name in CSS
# == just this file
: == Go to line

[sebastia...@gmail.com]

On Thursday, May 12, 2016 at 9:35:40 AM UTC+2, Karl Dubost wrote:

> Le 12 mai 2016 à 16:20, Sebastian Zartner a écrit :
> > Old thread, new input. I think there should also be a unified search and filter field component used across the tools.
>
> YES! As a first step before a unified search, at least a convergence.

Good, I've created https://bugzil.la/1272254 now for this.

> The debugger has a good search tool
> http://imgur.com/e3QtzFo
>
> In CSS
> ! == search in multiple files
> @ == search in Selectors name in CSS
> # == just this file
> : == Go to line

That's covered in https://bugzil.la/889571#c1.

Sebastian