TableWidget depends heavily upon XUL technologies. At the moment a table consists of a mess of XUL boxes that draw the table column by column. If this is the last uncomplete bug in bug 1263117 then we should check the status of our React Table to see if we can use that. If we can't use the React component then we should still convert the table to simple HTML.

Don't want to do extra work if we don't have to - could the widget added in Bug 1247065 be suitable for the storage inspector?

I think that's what he means by "React Table". It would be good for Mike to try that out and see what he thinks. I think there are still something we can improve on it but it will be easier to upgrade everything that uses 1 components instead of merge several different components together. Getting Mike's feedback for how it can improve would be good.

(In reply to Brian Grinstead [:bgrins] from comment #1) > Don't want to do extra work if we don't have to - could the widget added in > Bug 1247065 be suitable for the storage inspector? The main thing the storage editor needs that Honza's table doesn't include is editability. My plan is to convert storage.xul etc. to HTML and, when the table needs converting, see if we can use Honza's React table.

Another thing Honza's table widget lacks that the storage inspector needs is the ability to use multiple columns as primary keys e.g. for cookies the unique id should be three columns: - host - name - path

(In reply to Brian Grinstead [:bgrins] from comment #1) > Don't want to do extra work if we don't have to - could the widget added in > Bug 1247065 be suitable for the storage inspector? Yes, we should definitely use the existing widget and improve along the way. (In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #4) > Another thing Honza's table widget lacks that the storage inspector needs is > the ability to use multiple columns as primary keys e.g. for cookies the > unique id should be three columns: > - host > - name > - path This is for sorting? We should keep the basic tree-table widget simple and think what other features should be part of it and what should be implemented as separate component. I think that e.g. inline-editor is the first adept for and independent component. Honza

A big issue with this switch is that TableWidget.js is a live table with values switching all the time. Add double-click to edit and you can imagine what a minefield this is... after you double-click a cell to edit it all the rows around it can be moved or deleted. The current XUL table is built using vboxes for columns and hboxes for cells. We could easily change these to divs to convert the current table to HTML... in the interests of time I feel that this is the way we should go.

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #3) > (In reply to Brian Grinstead [:bgrins] from comment #1) > > Don't want to do extra work if we don't have to - could the widget added in > > Bug 1247065 be suitable for the storage inspector? > > The main thing the storage editor needs that Honza's table doesn't include > is editability. My plan is to convert storage.xul etc. to HTML and, when the > table needs converting, see if we can use Honza's React table. There's enableInput now: https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/components/tree/tree-cell.js#80 which allows you to reveal an input when clicking on a cell.

(In reply to Tim Nguyen :ntim (not accepting requests until 1st June) from comment #7) > There's enableInput now: > https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/ > components/tree/tree-cell.js#80 > > which allows you to reveal an input when clicking on a cell. Thanks for letting me know... that looks really promising.

Filter on HOTFROG.