Open Bug 1214202 (dt-widget-unity) Opened 9 years ago Updated 1 year ago

[meta] Devtools Widget Unity


(DevTools :: General, defect)

43 Branch


(Not tracked)


(Reporter: jsantell, Unassigned)


(Depends on 2 open bugs, Blocks 1 open bug)


(Keywords: meta)

Copied from the thread on the mailing list[3]:

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

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?)

Depends on: 1214311
Depends on: 1214312
Depends on: 1214313
Depends on: 1214314
Depends on: 1214318
Depends on: 1214323
Depends on: 1214324
Depends on: 1201742
Depends on: 1214325
Depends on: 1214326
Depends on: 1214327
Depends on: 1214328
Depends on: 1214382
Depends on: 1247065
Depends on: 1272254
Product: Firefox → DevTools
Depends on: 1692915
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.