This requires: - Protocol changes to the storage actor. - Front end changes to allow editing. Editing in the front end will be possible using the variables view where we allow editing the values, or plain text editing in a separate sidebar tab. For adding a new entry, a blank variables view can be presented in case of cookies. or we can just give a simple text box to begin with.

mass component move . filter on #MassComponentMoveStorageInspector

This patch contains the UI part of the bug and functional delete action. This also clubs into bug 1031194 as it adds the context menu. (I added context menu because without a toolbar, context menu is the only way to trigger edit actions) Next up is delete all and then edit and add.

Updated patch. - Edit, Delete, Delete All works for Cookies. Still looking why Add does not - Add, Edit, Delete, Delete All works for Local/Session storage - Things are still flaky wrt IDB. In this patch, the edit/add form once visible, stays there until the user presses cancel or switches to another item in the tree. So if you have 5 local storage rows, and you open the edit form, then even if you select any other row, the variables view sidebar won't appear. Is this UX behavior correct ? Any suggestions otherwise ?

Oh, builds at : https://tbpl.mozilla.org/?tree=Try&rev=673ee507a6bb

- Add for cookies is working now - Add/Edit for indexedDB items is working. Although, you will have to type in a JSON.parse-able stringified JSON value in the value text box. trying to figure out why delete/delete all are not working for indexedDB, while the code seems to be correct. New builds at : https://tbpl.mozilla.org/?tree=Try&rev=b701291c010f

Comment on attachment 8481970 [details] [diff] [review] WIP 3 Review of attachment 8481970 [details] [diff] [review]: ----------------------------------------------------------------- The UI for this is nice, but I would increase the size of the headings (Edit, Add) a little bit (kinda like the Edit and Resend header in the Netmonitor). ::: browser/devtools/storage/storage.xul @@ +48,5 @@ > + value="&storage.form.name;"/> > + <textbox flex="1" > + add-only="true" > + id="storage-form-name" > + class="tabpanel-summary-input"/> I think there's already a class which styles inputs (.devtools-textinput). ::: browser/devtools/storage/ui.js @@ +528,5 @@ > + } > + else if (action == "storage-edit") { > + this.showEditForm(type, host, this.table.selectedRow); > + } > + else if (action == "storage-add") { Why not a switch statement instead of this bunch of else ifs ? ::: browser/themes/shared/devtools/storage.css @@ +36,5 @@ > + background: #F7F7F7; /* Background-Sidebar */ > +} > + > +.theme-dark #storage-form { > + background-color: #343c45; /* Toolbars */ Don't see why this isn't following the sidebar background color. It'd be nice if you could switch to it, to ease up Brian's work on bug 947242.

:Optimizer Are you planning to resume your work on this? Florent

Rebased the patch and made it work again.

@ntim: Can you let us know the status of this bug... I mean, does the patch work?

Tim, Mike, would it make sense splitting this bug into smaller ones, so each storage feature can be tackled individually? Sebastian

(In reply to Sebastian Zartner [:sebo] from comment #20) > Tim, Mike, would it make sense splitting this bug into smaller ones, so each > storage feature can be tackled individually? > > Sebastian We can do that. We need a way to tell the table widget what is possible e.g. for indexedDB we only get a snapshot of the database and have no events for changes (they are coming) but obviously editing there is out of the question. For cookies though it should be easy. I won't have time in the next week to work on this so if you want to make a start you are more than welcome.

(In reply to Tim Nguyen [:ntim] from comment #22) > (In reply to Sebastian Zartner [:sebo] from comment #20) > > Tim, Mike, would it make sense splitting this bug into smaller ones, so each > > storage feature can be tackled individually? > > > > Sebastian > > I'm not too fond of doing this, because we may end up shipping code with > comments like "unimplemented", whereas here, we could have had written > multiple patches then ship them when everything is done. It allows to ship parts individually instead of having to wait until everything is done. I assume the code paths would be mostly independent, so there shouldn't be a high risk of "unimplemented" comments. > But since you've already filed bugs, that should be fine too. I've changed > your bugs to backend bugs, simply because it's more convenient to add an UI > when everything is done instead of handling uimplemented functionality in > the UI. Fine for me. I guess this still requires some more UI or backend bugs to be filed and a few bug dependency changes. Though I need to get some sleep now. > Also, I've merged edit/add with delete bugs since they share the > same underlying work. Might be the same underlying work, but different UI. But anyway, feel free to sort the bugs for your convenience. Sebastian