Last Comment Bug 674208 - Add a Properties context menu option to open the embedded properties pane in Bookmarks Manager
: Add a Properties context menu option to open the embedded properties pane in ...
Status: RESOLVED FIXED
[good first bug]
:
Product: SeaMonkey
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: seamonkey2.7
Assigned To: Jens Hatlak (:InvisibleSmiley)
:
:
Mentors:
Depends on: 696731
Blocks: 700045
  Show dependency treegraph
 
Reported: 2011-07-26 05:31 PDT by vkgoding
Modified: 2011-11-05 10:57 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed
fixed
fixed


Attachments
Screenshot. Bookmarks Managers showing the "Properties" (editing) section of the window. (21.19 KB, image/png)
2011-07-26 07:36 PDT, therube
no flags Details
Screenshot. (17.11 KB, image/png)
2011-07-26 07:37 PDT, therube
no flags Details
patch [Checkin: comment 10] (1.81 KB, patch)
2011-10-09 08:28 PDT, Jens Hatlak (:InvisibleSmiley)
iann_bugzilla: review+
philip.chee: approval‑comm‑aurora+
philip.chee: approval‑comm‑beta+
Details | Diff | Splinter Review

Description vkgoding 2011-07-26 05:31:19 PDT
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
Comment 1 therube 2011-07-26 07:35:00 PDT
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.
Comment 2 therube 2011-07-26 07:36:33 PDT
Created attachment 548448 [details]
Screenshot.  Bookmarks Managers showing the "Properties" (editing) section of the window.
Comment 3 therube 2011-07-26 07:37:56 PDT
Created attachment 548449 [details]
Screenshot.

 
Bookmarks Manager showing the "Properties" (editing) section of the window, collapsed.

Click the grippy to display.
Comment 4 Philip Chee 2011-07-26 13:00:35 PDT
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.
Comment 5 [:rickiees] Ricardo Palomares 2011-07-26 14:10:38 PDT
(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?
Comment 6 Jens Hatlak (:InvisibleSmiley) 2011-07-27 10:10:10 PDT
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).
Comment 7 [:rickiees] Ricardo Palomares 2011-07-29 02:13:09 PDT
Marked then as GFB and added to the wiki page.
Comment 8 Jens Hatlak (:InvisibleSmiley) 2011-10-09 08:28:56 PDT
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 9 Jens Hatlak (:InvisibleSmiley) 2011-10-11 23:36:38 PDT
Comment on attachment 565807 [details] [diff] [review]
patch [Checkin: comment 10]

Very low-risk change with no l10n impact improving UX
Comment 11 neil@parkwaycc.co.uk 2011-10-26 16:03:55 PDT
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.
Comment 12 Jens Hatlak (:InvisibleSmiley) 2011-11-05 10:57:48 PDT
(In reply to neil@parkwaycc.co.uk from comment #11)
> Unfortunately you forgot to inform the splitter that you wanted to
> uncollapse the deck.

Filed bug 700045.

Note You need to log in before you can comment on or make changes to this bug.