21.19 KB, image/png
17.11 KB, image/png
1.81 KB, patch
Ian Neal: review+
Philip Chee: approval-comm-aurora+
Philip Chee: approval-comm-beta+
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 Build ID: 20110706120824 Steps to reproduce: Clicked Bookmarks, Manage Bookmarks, selected a bookmark, right clicked, got Open....Cut, Copy, Paste and Delete drop down menu Actual results: Did same as always, get Open....Cut, Copy, Paste and Delete selections but not the usual "Preferences". Help, F1, tells me to do same as I did with no results. Expected results: Should have given me selection to edit and change the bookmark URL
Confirming that the Help is wrong. In any case, editing bookmarks is no longer done via a Properties dialog opened in its own window. Instead bookmarks are edited in place, in the Bookmarks Manager window itself. It is possible that the "grippy" is collapsed, such that the editing section of the window may not be visible. In that case, click the grippy.
Created attachment 548448 [details] Screenshot. Bookmarks Managers showing the "Properties" (editing) section of the window.
Created attachment 548449 [details] Screenshot. Bookmarks Manager showing the "Properties" (editing) section of the window, collapsed. Click the grippy to display.
I suggest that we morph this bug into: "Add Properties to the context menu to toggle the properties pane open (if closed). This makes the properties pane more discoverable.
(In reply to comment #4) > I suggest that we morph this bug into: > "Add Properties to the context menu to toggle the properties pane open (if > closed). This makes the properties pane more discoverable. Done (have I been too quick taking your suggestion as a task to be done?). Would this be a GFB?
Confirming as RFE (nothing's actually broken, that's why). (In reply to comment #5) > Would this be a GFB? Well, maybe not very first bug, but otherwise it should be as simple as this: 1. Add the new entry to the context menu (involves finding the right XUL file and code part therein, plus adding a new entity to the corresponding l10n file) 2. Connect the menu entry trigger with some JS code that toggles the splitter (ensures that the hidden part is made visible, maybe even adapting the height if it's below a certain minimum) 3. Test that the change does not regress anything (e.g. the new menu entry must only be added to bookmarks context menus of the Bookmarks Manager but not those within the browser bookmarks toolbar).
Marked then as GFB and added to the wiki page.
Created attachment 565807 [details] [diff] [review] patch [Checkin: comment 10] No l10n impact, woohoo! Let's sneak this into Aurora, shall we? Maybe even beta? :-)
Comment on attachment 565807 [details] [diff] [review] patch [Checkin: comment 10] Very low-risk change with no l10n impact improving UX
Comment on attachment 565807 [details] [diff] [review] patch [Checkin: comment 10] http://hg.mozilla.org/comm-central/rev/30e79f5daa63 http://hg.mozilla.org/releases/comm-aurora/rev/aa2f35d43399 http://hg.mozilla.org/releases/comm-beta/rev/062b443d5a8e
Comment on attachment 565807 [details] [diff] [review] patch [Checkin: comment 10] >+ var dd = document.getElementById("detailsDeck"); >+ if (dd) >+ dd.collapsed = false; Unfortunately you forgot to inform the splitter that you wanted to uncollapse the deck. So for instance in the Modern theme you notice that the uncollapse grippy still looks like an uncollapse grippy instead of a collapse grippy. And in any theme, clicking the grippy doesn't collapse the splitter, because it thinks it's collapsed and tries to uncollapse itself. Also the uncollapsed state doesn't persist. The correct code would be something like this: var dds = document.getElementById("detailsDeck-splitter"); if (dds) dds.removeAttribute("state"); etc.
(In reply to email@example.com from comment #11) > Unfortunately you forgot to inform the splitter that you wanted to > uncollapse the deck. Filed bug 700045.