1247973 - Distinguish between editable and non-editable cells in the storage inspector

Status: RESOLVED WONTFIX

(DevTools :: Storage Inspector, enhancement, P3)

Description

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

We will soon have an editable storage inspector.

In the storage inspector we have editable cells in the table but not all columns are editable (generally the first 1 - 3 columns are read only, usually just 1).

We need a way to distinguish them.

Ideas:
- We could put lock in the column header.
- We could decrease the opacity of uneditable cells (makes it look disabled, like with inputs).

I guess you want the bug to create the lock icon unless decreasing the opacity would be enough.

Comment 1

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #0)
> We will soon have an editable storage inspector.
> 
> In the storage inspector we have editable cells in the table but not all
> columns are editable (generally the first 1 - 3 columns are read only,
> usually just 1).
> 
> We need a way to distinguish them.
> 
> Ideas:
> - We could put lock in the column header.
Are entire columns uneditable?

> - We could decrease the opacity of uneditable cells (makes it look disabled,
> like with inputs).
I think this would be the best course.

> I guess you want the bug to create the lock icon unless decreasing the
> opacity would be enough.
It's hard to say without seeing it. Let's decrease the opacity first and then make a call as to whether or not the lock is necessary.

Comment 2

[Girish Sharma [:Optimizer]]

What's the plan as of now? Will the editable cells be in-place editable? or a sidebar will appear with input boxes...

Comment 3

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Girish Sharma [:Optimizer] from comment #2)
> What's the plan as of now? Will the editable cells be in-place editable? or
> a sidebar will appear with input boxes...

If this is something where now is the time to decide, Michael, I think in-place editing might be best :)

Comment 4

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #3)
> If this is something where now is the time to decide, Michael, I think
> in-place editing might be best :)

It occurred to me that it might be useful to add some notes about what the UX of this would be like.

In the inspector, when you change a value/attribute of a node, the node briefly flashes white to indicate that the value has been changed. I think reusing that pattern would be nice here.

Comment 5

[Girish Sharma [:Optimizer]]

(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #3)
> (In reply to Girish Sharma [:Optimizer] from comment #2)
> > What's the plan as of now? Will the editable cells be in-place editable? or
> > a sidebar will appear with input boxes...
> 
> If this is something where now is the time to decide, Michael, I think
> in-place editing might be best :)

Both Local Storage and IndexedDB are in general key-value pairs and the common use case is to store jsons as values. In indexed DB, we have binaries as well, but lets keep that aside. Editing JSON in an in place input box might not be very useful.

Comment 6

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #4)
> (In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #3)
> > If this is something where now is the time to decide, Michael, I think
> > in-place editing might be best :)
> 
> It occurred to me that it might be useful to add some notes about what the
> UX of this would be like.
> 
> In the inspector, when you change a value/attribute of a node, the node
> briefly flashes white to indicate that the value has been changed. I think
> reusing that pattern would be nice here.

The editing is inline and works just fine. Our platform doesn't allow the name, path or domain of a cookie to be changed so those three columns needed to be read only. The same will be the case for other tables e.g. indexedDB where the key shouldn't be editable.

You just double-click a field to edit it and, of course, tab and shift tab take you through the fields in edit mode. Escape cancels edit and enter or tab applies the change.

Opacity didn't look so good so I used a white and black background with alpha instead.

For now I am leaving non-cookie tables untouched rather than highlighting them all to say they are currently read-only.

Screenshots of the read only tables to follow.

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Dark theme.png

Comment 8

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Light theme.png

Comment 9

[Helen V. Holmes (:helenvholmes) (:✨)]

Looking over the screenshots, I think having the lock icon would be helpful (right now I don't think the distinction is clear enough).

I'll try to get that asset to you within the next couple of days.

Comment 10

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: lock.svg

Comment 11

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Would you still like us to add the lock?

Comment 12

[Helen V. Holmes (:helenvholmes) (:✨)]

I think adding the lock would still be a good idea, but I think you've right on priority :)

Comment 13

[Helen V. Holmes (:helenvholmes) (:✨)]

I'm going to unassign myself from this since I'm not actively working on it in any way.

Comment 14

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

We have discussed this as a team numerous times and adding padlocks would take too much space. People are generally happy with the current UX.