Quote from the specification: Menu Design Principles 1. Provide convenience [...] 2. Provide power [...] 3. Provide speed [...] 4. Menu items should be ordered by frequency and/or relevancy to the immediate context and task Every single of the top four design principles is violated by the decision to delete the Back/Forward/Reload/Stop-block from the inline image context menu. Forcing the user to either hunt for a non-image part of the web page (which can be quite hard as transparent or background colored images are a frequent part of current designs) or completely remove the mouse pointer from the viewport to use basic navigation features. Because of the non-obvious images of many web designs I'd even add a violation of the principle of least surprise to the list, even if it is not a stated design goal. This non-feature is certainly neither convenient nor powerful nor fast. In fact the first choice in the proposed inline image context menu is "View image" - which is usually exactly the thing the user did before activating the context menu (rare cases of images scaled by width/height attributes excepted). The basic navigation commands are probably much more frequent in this context. One may argue that links (plain, images, etc.) don't offer this navigation block either, but in that case the different context is traditionally indicated to the user by a change of the mouse pointer shape so it is very easy to avoid those contexts when desired. Additionally the top choices in those context menus have a higher "navigation value" compared to the "View image" choice in the plain image context menu. The same arguments could be applied to the Selected Content Menu, there are certainly cases where it is not obvious that some text is selected (search results in long web pages, invisible selection color, ...) and the user is confronted with an unexpected choice of options.

This is our bug system. This is not your "complaint box" and it's not your newsgroup discussion forum. Continue to abuse our bug system and your account will be disabled. A decision was made on the context menu bug. Don't like it? Start your own project and do it better. Wasting developers' time with issues that have already been decided does nothing to further your cause and does everything to make developers want to ignore non-developers completely.

Dear Asa, a decision has been made by whom? This bug was carried over from a another one which has hundreds of IMO constructive comments why the decision you mention was a bad one. I dont know how many of these comments do come from contributors who have actually helped to improve Mozilla, but some do. This bug exists, because a decision was reached that actually keeps contributors from implementing a frequently wanted feature. I dont say that the proposal in this bug is a good one or should be implemented but to call it an abuse of bugzilla is a bit harsh. Maybe you should not piss off contributors of an opensource project that to a significant extend is only possible because external people care and help with design and implementation. If you want their coding work you will have to listen to their design suggestions too. I dont like people wasting my, acontributor's, time by wiping away good arguments without any plausible reasoning by just saying "a decision has been made", as it is the case in the bug from where this has been spun off. And this is, I must tell you, any Mozilla contributors bug system. If you dont like people to care and to get pissed off by bad decisions, make your project closed source and dont give passwords out for it. You will have a whole lot of more work to do then than just deal with bugzilla posting you do not like personally.

Ingo: It is a context menu because it deals with what is highlighted or selected (its context, that is). If something applies to the entire viewport like the Forward, Back, etc. options, then they do not belong in the context menu. Of course, you are free to maintain your own XUL or create you own addon project to add the options.