Closed
Bug 309740
Opened 19 years ago
Closed 19 years ago
Some windows have non-context-sensitive context menu items that aren't also in menus or toolbar buttons
Categories
(Firefox :: Shell Integration, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: bugzilla-support, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Functionality should not exist on a context menu without the visual cue through a standard UI element. This is a fundamental break of UI expect- ation for the average user. The user has no information to deduce that a context menu exists in a certain situation. I personally thought there was a bug in the Help Viewer especially as the UI is very, very simple (2 buttons and a text input box). I assumed therefore that when my help window kept permanently obscuring my browser that there was a bug, when in fact there wasn't; it was actually the fact that a Context Menu existed for the Help Viewer with an "always on top" option that was *checked by default*. Where was the menu option, or toolbar button, that allowed me to change the "always on top" option? Where was the menu option that could suggest that the vast expanse of open nothingness that is the Help Viewer background actually supports a context menu? Had I seen the existence of the feature on the menu bar, for example, I might have assumed that, for ease of use, a context menu option could exist and so I *might* have tried a context menu click on the page somewhere. However, as the "always on top" feature was also UNDOCUMENTED, searching the help didn't yield any joy either so I rightly assumed there was a bug, and I actually filed a bug and wasted a day of development time on a wild-goose chase with analysis tools and debuggers (see Bug #309300). Functionality should not be put on Context Menus without being on a menu or a physical button first. Reproducible: Always Steps to Reproduce: 1. Open any of the following: Source Viewer, Extension Manager, Themes Manager, Help Viewer. 2. Right-click somewhere on the page background. 3. Observe the menu options and compare to the number of physical UI elements on the page that suggest that this menu is operating in the context of a wide operation. Actual Results: The menu reflects vastly more options that the User is aware actually exist through physical UI cues (e.g. menus, toolbar buttons, etc.). The result is that the User may not, in some instances, feel that a context menu actually *exists*, and misses functionality. Expected Results: If a context menu is given to the user, EVERY feature on the menu should be backed up by a physical menu-bar menu option or a toolbar button.
Updated•19 years ago
|
Summary: UI integration broken for context menus (all platforms?) → Some windows have non-context-sensitive context menu items that aren't also in menus or toolbar buttons
Comment 1•19 years ago
|
||
There is no requirement for context menu actions to be reflected in other UI elements. In particular, advanced options may be there, especially in windows without menubars. Its not perfect, or eminently discoverable, but that's part of the balance in terms of uncluttered UI.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•19 years ago
|
||
I'm not going to comment on this any further except to say that whilst you think there is no requirement, I, as a USER, and at least one other person (who did leave a comment in the bug report) thought this was a bug. If two people find it was a bug in the space of two days, how many people in the world have not potentially adopted Firefox because of this and similar problems because they couldn't be bothered to say anything? This is about what the Customer finds most usable, and what is most obvious to the Customer. It's not about aestetics or clutter. Usability. Not prettiness. I said enough about focussing on the customer here (bug #309798). In my opinion, another example of "Well I think it's best, so the customer can like it or lump it". A sad day for the Customer.
Comment 3•19 years ago
|
||
Andre, you're talking about Help in particular in comment 2, right? Why don't you file a new bug on just that instead of just whining about your general bug being WONTFIXed?
Reporter | ||
Comment 4•19 years ago
|
||
Because it's(In reply to comment #3) > Andre, you're talking about Help in particular in comment 2, right? Why don't > you file a new bug on just that instead of just whining about your general bug > being WONTFIXed? Why don't I file a bug about the Help system? Because it's not a bug in the Help system. I'm not saying the Help isn't working, and I never said it didn't. It was a usability issue that I found through my experiences with the Help that I found to be actually replicated in 3 other areas of the product. That's why it's a general usability bug not a Help specific one. Forgive me for "whining" some more.
Reporter | ||
Comment 5•19 years ago
|
||
(In reply to comment #1) > There is no requirement for context menu actions to be reflected in other UI > elements. In particular, advanced options may be there, especially in windows > without menubars. Its not perfect, or eminently discoverable, but that's part > of the balance in terms of uncluttered UI. As an example of what is considered good, untuitive UI design, and as something that demonstrates very easily how all the issues raised in this query could be resolved, all areas of the product should just copy the excellent Bookmarks Manager window implementation.
You need to log in
before you can comment on or make changes to this bug.
Description
•