Created attachment 854407 [details] Grayed out bookmark options Description of problem: When focusing on a child node of the system tree, bookmarks option are grayed out, and can not be removed or edited. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Add a new bookmark from the search bar 2. Go to the System tree 3. Click "Data centers" 4. Click the "Bookmarks" tab 5. Right click the bookmark you have just created Actual results: Edit and Remove options will be grayed out Expected results: Edit and Remove options should be operational Additional info:
Created attachment 855001 [details] screen-shot: a seemingly-selected bookmark vs. an actually selected bookmark
this is actually not entirely related to being focused on a child node of the system tree (although the problem is indeed more painful in that case): currently, we don't have a way of editing a bookmark without selecting it. i.e., today, if you want to edit a bookmark, you must select it first. this is wrong, since selecting a bookmark applies that bookmark on the application, and the user doesn't necessarily wants to do that, so we need to find a solution for that. [specifically, when a child node is selected on the System tree, the bookmarks are disabled (by design, IIRC), so you cannot actually select them, therefore you cannot edit/remove them at all in this context, which makes the problem described above even more "painful"] another problem that we have is that the GUI is misleading - see attachment 855001 [details]: when you are right-clicking a bookmark, the bookmark's background becomes yellow, which implies that it is selected in some level, so the user may expect that the displayed context-menu will be shown in the context of this seemingly-selected item (allowing Edit and Remove of this item, for example); however - this is not the case: the item is actually not selected at all, and the context menu is indeed displayed in an "empty" context (i.e. only the "New" action is available from it). In my opinion, we should do the following: (1) find a way of editing a bookmark without applying that bookmark to the application (maybe we can fix the behavior so that a bookmark that is being right-clicked and colored yellow will actually be selected for edit/remove purposes, but will not be applied to the application - may be tricky to implement though; we can also consider an entirely new concept). (2) IMO, we need to enable applying bookmarks even if we are focused on one of the System tree's child nodes (even if it means temporarily selecting the "System" root tree-node "behind the scenes" once going to the "Bookmarks" section, and returning to the last-selected-by-user tree-node when returning to the "System" section). 'needinfo'ing Eldan/Malini for their thoughts.
Agree with Einav on both issues. I think the main problem is that the bookmarks are selected and not just clicked. What I mean is when a bookmark is clicked, it stays selected. Same for the tree's nodes: when a node is selected it stays selected. But we can only have 1 selected (blue background) entity over the bookmark/tree area. Solution: Bookmarks should be treated as "simple buttons" - you click a bookmark and it doesn't stays selected, in that way, we could get what Einav proposed in her 2nd issue: -You are focused on a tree node and can still click a bookmark. And the problem of remove/edit a bookmark is solved since there is no significance to a selected bookmark.
Bug 1059646 will be solved as well according to the proposed solution.
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
This issue still stands. bug 1059646 was fixed, can we fix also this one? (maybe in next release?).
(In reply to Pavel Stehlik from comment #6) > This issue still stands. bug 1059646 was fixed, can we fix also this one? > (maybe in next release?). bug 1059646 (or, bug 1052151) was resolved by making sure that when we are focusing on the "Bookmarks" section, the "System" (root) tree-node in the System tree gets automatically selected. so I consider this BZ to be resolved: when selecting a non-"System" tree-node in the system tree, and focusing on the Bookmarks section - bookmarks editing are now enabled. however (as sort-of a "release note"), after the user is done with editing the Bookmarks and going back to the "System" tree, the tree will have the "System (root) node selected, and not the last-selected (non-"System") node as he may expect. I am not sure if pursuing a solution for the "release note" above is worth the effort - I am not sure how popular of a use-case it is, and we are planning to eliminate the System tree altogether for 4.0 anyway. Therefore, I recommend to close this bug. If you have any questions or comments that require any additional feedback from me - please feel free to 'needinfo' me again. Thanks!
As per c#7 explanation - 4.0 should solve this issue.