Bookmark context menu entry order regression/issue
Categories
(Firefox :: Menus, defect)
Tracking
()
People
(Reporter: reg-bugzilla, Unassigned)
References
Details
Attachments
(2 files)
Shot_8.jpg
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0
Steps to reproduce:
Open bookmark entry context menu.
Actual results:
back the old bookmarks bar context menu entry order.
Now, it is so confusing to use it as it is against all other context menu orders. Putting the most dangerous entries to the top and those more often used ones to the bottom.
I did delete entire bookmark folders by accident several times because the oder really confusing. Please, bring back the old order.
Expected results:
Please bring old context menu entries order back.
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Menus' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•4 years ago
|
||
This reorganization was done intentionally in bug 1692668.
t-ask, you wrote:
it is so confusing to use it as it is against all other context menu orders
Can you show me a screenshot of one of these other context menu that this organization goes against, and how you got there?
Sure, open Thunderbird and look for events and task lists and look at their context menus.
The common sections order of context menus is more or less: "open/add - create - copy/paste - modify - delete - properties"
Current Firefox menu order in instead: "open - modify - remove - sort - copy/paste - add".
Especially the add and remove section orders are odd here (look my initial screenshot). Please revert to what it was for decades already. It was fine, working nothing really against the common UX.
Please revert to old order it matches better with other software, does prevent from accidentally deleting entire bookmark trees and it was this for decades, there is no benefit from current state.
|
|
||
Comment 4•4 years ago
|
||
Sorry t-ask, I should have been more precise with my question: are there menus internal to Firefox (as opposed to within other applications) that the new organization contradicts?
(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)
Sorry t-ask, I should have been more precise with my question: are there menus internal to Firefox (as opposed to within other applications) that the new organization contradicts?
Mmm, I'm not sure if it makes sense to compare this menu with other menus within Firefox. Especially, because those menus have quite different underlying structures to support. I added another picture which at least gives a rough idea why the bookmark context menu has an odd section order.
I would rather suggest comparing it with other list context menus of other applications, as my report is more focusing on the unusual order of this menu compared to other applications.
|
||
Comment 7•4 years ago
|
||
I don't think we're likely to fix this. The reordering was intentional. It doesn't really make sense for "create" options to be near the top of the list when clicking existing items - arguably, they shouldn't even show up, and only show up in blank spaces.
The comparison in attachment 9238666 [details] is a bit confusing - it links editing and deleting with "close tab", but not with all the other operation that alter the tab (reload it, mute it, pin it, etc.). It also suggests that "open bookmark in tab" should be grouped with "create a new bookmark" when those are very different operations anyway. So I don't think it makes a convincing argument for a change.
We're updating the labels in bug 1714478 which will hopefully help with selecting the correct entry in the menu.
(In reply to :Gijs (low availability; he/him) from comment #7)
I don't think we're likely to fix this. The reordering was intentional.
What was the intention? Just the distance of mouse movement. Where can I read the deatials to understand the deecision better?
(In reply to :Gijs (low availability; he/him) from comment #7)
It doesn't really make sense for "create" options to be near the top of the list when clicking existing items - arguably, they shouldn't even show up, and only show up in blank spaces.
I could say, "Is it better to move often used add-sections to the bottom?" I wonder wahtis behind this idea? I can't remeber having seen something like this somewhere else. Mac? Moving the less destructive and more often used section to the bottom while moving dangerous options to the top is strange. Is this coming from mobile UX design guides? What was the problem of the classic layout?
(In reply to :Gijs (low availability; he/him) from comment #7)
The comparison in attachment 9238666 [details] is a bit confusing -
Well, this is what I said before. It is not a valid approach to ask for a comparison of very different context menus only inside Firefox if the bug report was on comparing the order to the old one (more standard one). This is waht I said before:
(In reply to t-ask from comment #5)
Mmm, I'm not sure if it makes sense to compare this menu with other menus within Firefox. Especially, because those menus have quite different underlying structures to support. I added another picture which at least gives a rough idea why the bookmark context menu has an odd section order.
I would rather suggest comparing it with other list context menus of other applications, as my report is more focusing on the unusual order of this menu compared to other applications.
(In reply to :Gijs (low availability; he/him) from comment #7)
it links editing and deleting with "close tab", but not with all the other operation that alter the tab (reload it, mute it, pin it, etc.).
I'm not sure what you refer to with "it" here. If you mean the blue line, then it links all options which remove/delete and the rename one I accidentally selected, too. Can happen, but it still shows that in most context menus the "remove/delete" section is more to the bottom than on a prominent top/dangerous position.
(In reply to :Gijs (low availability; he/him) from comment #7)
It also suggests that "open bookmark in tab" should be grouped with "create a new bookmark" when those are very different operations anyway. So I don't think it makes a convincing argument for a change.
It was just my quick response to the request before.
The bug report was about comparing the new with the classic context menu order and its problems, I see.
I'm not saying "you should do A or B" exactly as shown. I rather ask for an open discussion to improve usability while reducing the the risk to loose a lot of bookmarks. The classic context menu is more intuitive by supporting decades of standard context menus for editing list boxes.
We're updating the labels in bug 1714478 which will hopefully help with selecting the correct entry in the menu.
This only changes the naming of entries, not the order of sections or entries themselves.
I'm not sure how often one organizes huge hierarchically bookmark structures here, but I can tell, it is now way easier to accidentally click the wrong option. And I did try for weeks to get used to this new order, before desiding to open this report.
Reading the WONTFIX so early, after not having openly discussed the main subject of the bug report, based on requested "non-matching examples", disappoints me. I expected a more fair and constructive approach to improve the situation, instead.
Description
•