Some windows have non-context-sensitive context menu items that aren't also in menus or toolbar buttons

RESOLVED INVALID

Status

()

Firefox
Shell Integration
--
major
RESOLVED INVALID
13 years ago
13 years ago

People

(Reporter: Andre Sihera, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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

13 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
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
Last Resolved: 13 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

13 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

13 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

13 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

13 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.