For the yellow star in location bar, implement a context menu that provides intuitive and fast access to (additional) functions involving the bookmark. Have a look and try it out yourself in the mock-up context menu which I have attached to this comment. For an existing bookmark, the context meny of the yellow star should at least have the following options: - Edit this bookmark (default) - Organize Bookmarks (will open the bookmark in the Library) - Remove this bookmark Having "Organize Bookmarks" on the context menu (which will select the bookmark in the library) might be a low-cost workaround fix for the justified complaint of bug 405795 where users are frustrated that they can't access all properties of a bookmark from the yellow star (in fact, there's NO place in FF where you can edit ALL properties of a bookmark directly, but that's another story). For a URL which hasn't been bookmarked yet, the grey star's context menu should at least have the following commands - Bookmark this page The current context menu of the star shows toolbar customization options, which doesn't feel right on such an outstanding object like the bookmarking star. Comments on the proposed UI are welcome.

Comment on attachment 391081 [details] Interactive Mockup of proposed context menu for yellow star Alex can probably evaluate this, btw i'm not sure undiscoverable context menus are so useful for quick bookmark access.

Agreeing with comment 2. We'll let the module owner decide though.

Marco, have a look at bug 405795 and its duplicates, or bug 404507 and its duplicates to see how frustrated people are that there is no direct way whatsoever to edit all of a bookmark's properties (esp. Keyword) after you have created the bookmark using ctrl+D or star button. People see the bookmark (i. e. the star) right in front of them, but they can't do anything with it apart from the crippled options of "Edit this bookmark" popup. What they then have to do is open bookmarks manager ("Library") from the menu and do a manual search for the bookmark, and even then (from search results) they still won't be able to see what folder the bookmark is in, let alone change that folder. We have at least 3(!) different "Edit bookmark" dialogues/UIs and NONE of them lets you change all the properties. To tell you the truth (against nettiquette, I'm sorry), it sucks. So I think anything which creates some sort of link between the bookmark star and its actual properties will be a step ahead. Adding a context menu to the star is ONE way (surely not the best) of creating the link, and it comes at a far lower cost than changing the primary UI for the star's "Edit this bookmark" dialogue (for which to be fixed we'll probably have to wait for more duplicates, more votes, more discussions, and more years). And yes, I can't code yet and I don't have the time to, so please don't advice me to come up with a patch. I don't think there can be anything "undiscoverable" about context menus for primary UI elements, which the star clearly is. I think it's obvious from bug 405795, bug 404507 and their dupes that people have come to think of the star as "the bookmark's object". What do you do when you're looking for (more) commands on a specific object? Personally, first thing I do on any object I'd like to manipulate is check out the context menu (which is what I did before posting this bug). Come on, context menus are *everywhere*, you can even right-click on FF's back button (how discoverable is that?), on the quicksearch box, or on Windows Start button. Call me sensitive, but I don't like the subtle irony of your comment #2 which somehow seems to sound like "the enhancement you propose will be useless, but anyway, let's have a look before we discard it". Maybe it's because we've had that too often: too many sensible, valid and intelligent user requests and complaints have just been turned down by the people in charge in a very nonchalant manner, just to languish unaddressed for years until the number of duplicates, votes and frustrated comments finally made someone feel that maybe the original idea wasn't so bad after all. I believe the only way for a software to evolve is listening to any serious user feedback with utmost appreciation and try to be as creative, imaginative and flexible as possible when it comes to improvements and innovation. But maybe you are right - instead of suggesting a fairly easy workaround that may later be misused as another excuse for the incomplete design of the "Edit this bookmark" dialogue, I should have spent my valuable time trying to let people know that "wontfix?" for bugs like bug 405795 or bug 404507 with duplicates already coming in may seem both arrogant and short-sighted and is likely to drive users nuts. That is, those users who are still so interested in improving their favourite Mozilla products that they bother filing bugs and defending their ideas in a bug system that still submits your personal email address to the spamming public and doesn't even have a "back to your bug X" link after you have voted for a bug, that's if you still believe in votes. That said (am I being negative?), I appreciate Marco's instantaneous reaction and I'll be interested in the outcome of any care-ful and thought-ful ui-review. Sorry for flaming. Marco, it's not your fault, your comment was just the trigger. I'm a complete newbie to XUL, so coding the mockup took me some considerable time, but knowing how critical folks at mozilla can be, I wanted to provide a clear illustration of the proposed look and feel. And then the first comment you get, well, you know... Hey yea, and then the second comment you get, after "Mid-Air-Collision", is a suggestive "wontfix?" inquiry at the top of your bug. Better don't spend a second thought on unexpected ideas, it might improve your software. BTW, this bug is not primarily about "quick bookmark access", it's about providing access AT ALL to a more complete set of properties. Thanks anyway!

Writing a page-long rant isn't a productive way to handle this. I'll be honest, I didn't read it, so I'm replying to comment 0 only. * Remove Bookmark is in the left click UI, so we're duplicating functionality here. Not useful. * the Organize Bookmarks use-case seems very power user-ish. Really, what you want is "Show This Bookmark in Library" as the string. I don't think the use-case is that compelling, and seems a little tacked on. * The "can't edit all properties of the bookmark" piece is probably not best solved by a context menu option on an unfocusable element. It's not accessible, so we'd need another solution anyway. I'm going to comment on bug 405795 shortly. I really get the sense that this is being proposed to get the third point worked around, but that's not really a great way of solving the problem. We can and should do better. Marking this WONTFIX.

[Short summary] IMHO the wontfix resolution for this bug should be reconsidered, and it should be reopened. My understanding of "wontfix" is that even if someone would want to implement this, they shouldn't. However, this seems to be a valid and useful enhancement at no cost / without any real disadvantages. Details below. [Details / Reasons] 1) Bug 424044 calls for implementing contextual menus for ALL UI elements of the location bar, including the star (other elements: favicon, rss icon, history dropdown etc.). 2) The discussion in related Bug 428304 (right-click on star should remove bookmark) is also interesting for this bug because it has many comments from respected persons that all suggest/accept the idea of having a context menu on the star (as suggested by this bug and bug 424044). E.g. Jesse Rudermann, bug 428304, comment #2 (to cite just one): > users would right-click the Star, hoping to get a context menu (Bug 428304 was rightly rejected because it wanted a delete action triggered by right-click, which was clearly a problematic approach, and people said context menu would be the right approach.) (In reply to comment #5) > * Remove Bookmark is in the left click UI, so we're duplicating functionality > here. Not useful. 3) !? *Every* contextual menu duplicates existing functionality, so as to provide an easy and unified in-place access to element-related commands. I have no reason to assume this couldn't be useful (it is for me), plus it doesn't hurt to have it. > * the Organize Bookmarks use-case seems very power user-ish. > Really, what you want is "Show This Bookmark in Library" as the string. 4) You are right, "Show this bookmark in library" would be the better string. > I don't think the use-case is that compelling, and seems a little tacked on. 5) "Show in library" is basically the same as "Open containing bookmark folder". That use case is so compelling that it has several bugs filed for it (all of these bugs want a way to know and/or "open the containing folder" of a single bookmark object at hand, and the star is just another representation of a bookmark object): - Bug 469441, currently 12 votes (Add "Open Enclosing Folder" to search results of bookmarks...) - Bug 469421, currently 21 votes (Add folder column to search results for bookmarks...) - Bug 56418 (Seamonkey equivalent), currently 84 votes (Add folder column...) Surely all these people don't just want to /know/ the containing folder... "Open containing folder/Show this in library" OK, you may call this "tacked on". What I see is that a lot of users have a strong need to view a bookmark's containing folder. Having a context menu entry for that action on the star bookmark object will be appreciated by such users, regardless whether such functionality might be available elsewhere (which it isn't, currently!). > * The "can't edit all properties of the bookmark" piece [bug 405795] > is probably not best solved by a context menu option on an unfocusable > element. It's not accessible, so we'd need another solution anyway. 6) The fact that the context menu suggested by this bug isn't the best solution for another bug (as I agree with you) doesn't mean that this proposed enhancement couldn't add value. Many context menus in FF are on unfocusable elements, e.g. on the back button, all toolbars, and tabs. Should we abolish the context menu on tabs because it's an unfocusable element? Since we are deliberately duplicating /existing/ functionality (or such that will exist after the respective bugs have been fixed), I don't think accessibility is an issue here. This is about workflow, UI intuitions and usability. And I /am/ a user, and not the only one with the same intuitions (see related bugs above, especially bug 424044). Besides (please prove me wrong!), I bet my ... that we'll wait long until bug 405795 will get adressed, whereas this little context menu would be far easier and thus faster to implement, without hurting anyone. Some workaround may be better than no workaround... 7) Another personal reason why I am coming back to this: Each time I want to delete an active bookmark, I automatically want to click the right mouse button to get the context menu on the star. It just doesn't feel right to go to the properties panel and delete the bookmark "from within". I don't think there are many programs that let you delete anything "from the inside" of the object that will be deleted (files etc.). Which might be a natural intuition, because you don't usually go inside things before blowing or throwing them away. 8) Context menus on primary UI elements can never be undiscoverable (against comment #2), on the contrary. For details, see comment #4. 9) I haven't heard any reasons so far that point out an actual *disadvantage* of having a context menu on the star, or a violation of UI princinples. I'm not expecting that FF developers implement this, but maybe someone else wants to. They should be allowed (please remove wontfix!). > Writing a page-long rant isn't a productive way to handle this. I'll be > honest, I didn't read it, so I'm replying to comment 0 only. 10) I admit that the length and the mood of my comment #4 are unfortunate, and so is the fact that you are not reading relevant comments before wontfixing new ideas. Personally, when it comes to discussing UI issues, I don't see any alternatives for using multiple arguments and make them as precise as possible. Generally speaking, "I feel this is bad / I don't like this" by developers is not much different in class from "This bug sucks" by users. Both are not helpful, as they are not based on detailed arguments. I'm aware I'm not good at cutting my points short, but the points I make are usually carefully considered and I do believe they are worth reading. Maybe even the flame ones. Had you read my comment #4, you'd also know why (something about sensible user input being ignored and turned down for years until it finally turns out they were right). Above all, it's that I care for my favourite browser. :)

you're in the wrong place for this kind of design comments, you should bring the discussion to a newsgroup, and then just report final considerations to a bug, since a comment of this size on a bug would discourage anyone willingto read it. the point about context menu is that it should reduce the path user has to take to execute the action, actually edit the bookmark is 1 click (click on the start) with context menu would be 2 clicks. Remove bookmarks is 2 clicks (click on the start, click on remove), context menu is 2 clicks (no win). Organize bookmarks is 2 clicks (Bookmarks/Organize bookmarks), with context menu is 2 clicks (no win). but please, bring proposals to a moz newsgroup and post just final considerations to bugs.

(In reply to comment #7) > you're in the wrong place for this kind of design comments, you should bring > the discussion to a newsgroup, and then just report final considerations to a > bug I'm suprised (at least), as I've never ever seen a bug which is limited to "final considerations"; especially with enhancement bugs this seems very much impossible. But I see you are taking offence in the length of my postings (regardless of the content), and apparently (sadly) it does seem to discourage even competent people from reading it. Personally, I feel that digging into moz newsgroups is another burden I am currently not willing to take, and I don't have the time to. But perhaps you could let me know the name/URL of the right newsgroup where enhancement requests like this one should be discussed. btw, merely based on your method of "counting clicks", a lot of context menus should never exist in the first place. IN-PLACE editing is the keyword here. > Organize bookmarks is 2 clicks (Bookmarks/Organize bookmarks), with context > menu is 2 clicks (no win). Well, NO... But it's my fault that you are getting one of the key points of the suggested enhancement wrong, because I chose the wrong label in the mockup of attachment 391081 [details]. This isn't about "Organize bookmarks" in the sense of just "Open the library" (which would be 2 clicks, indeed). As per my comment #1 (still short!) and Mike's comment #5 (that's a short one, too ;)), it's "Open/Show *this bookmark* in the library". You show me how to do that in 2 clicks, and we could as well close down all of those bugs I mentioned in comment #6, number 5), and make more than 100 users who voted for those bugs very happy. But then, you don't like reading my comments. Fair enough. eom.

just FYI, i read comments before replying, or would not even reply. I'm just pointing out that long posts on bugzilla tend to be ignored, is not a personal thing, just what tends to happen. So directing energy better would gain better results. You have a good point about exposing the containing folder, but that can have better impementations than a context menu here. mozilla.dev.apps.firefox can be a good choice for large discussions.

(In reply to comment #5) > Really, what you want is "Show This Bookmark in Library" as the string. Revised interactive mockup of the proposed star context menu as per Mike's comment #5. Improved layout and mockup code cleanup.

See also bug 582907.