Status bar icons should respond to right-click

VERIFIED WONTFIX

Status

()

Firefox
Menus
P4
trivial
VERIFIED WONTFIX
15 years ago
12 years ago

People

(Reporter: Greg Campbell, Assigned: mconnor)

Tracking

({polish})

unspecified
Firefox1.0beta
x86
Windows XP
polish
Points:
---
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030810 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030810 Mozilla Firebird/0.6.1+

The stylesheet switcher icon in the status bar should display the menu upon
right-click.  Currently it only displays on left-click.  Windows contextual
menus should display on right-click.

Reproducible: Always

Steps to Reproduce:
1. Right-click stylesheet switcher icon in status bar.

Actual Results:  
Nothing.

Expected Results:  
Display the menu that displays when this icon is left-clicked.

Comment 1

15 years ago
Re-assigning to Menus and confirming.
Severity: minor → trivial
Status: UNCONFIRMED → NEW
Component: General → Menus
Ever confirmed: true
QA Contact: asa → bugzilla
(Assignee)

Comment 2

15 years ago
its not a context menu though, however I don't see a big problem implementing this

-> taking
Assignee: blake → mpconnor
(Assignee)

Comment 3

15 years ago
actually, who knows if we'll want to support a separate contextmenu in the
statusbar on right-click at some future time.  It could happen, whether its
likely or not is irrelevant, because we have to allow for future UI decisions.

Given that this isn't a context menu, there's no need to duplicate this
functionality.  There's no reason to assume that this is a context menu at all,
and the other statusbar icon that appears is triggered by left-click.

-> WONTFIX
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 4

15 years ago
The only other apps I can find that have an icon-in-the-status-bar interface are
the MS Office apps. The system tray also is a similar interface. All these icons
only respond to right-click, and do nothing upon left-click. I'm sure this is so
obscure that there is no interface guideline. I, for one, always intuitively
right-click the icons in the status bar. The only things in Windows that get
left-clicked and pop a menu are the Start button and menus, neither of which
these icons resemble.

For what it's worth, the pop-up indicator responds to left-click AND
right-click. Having status bar icons respond to right-click wouldn't break
future right-clicking in the status bar any more than allowing bookmark toolbar
items respond to right-click does.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 5

15 years ago
> For what it's worth, the pop-up indicator responds to left-click AND
> right-click. Having status bar icons respond to right-click wouldn't break
> future right-clicking in the status bar any more than allowing bookmark toolbar
> items respond to right-click does.

I was thinking specifically for those icons, I thought the popup icon only
responded to left-click, my bad.
Status: REOPENED → ASSIGNED
(Assignee)

Comment 6

15 years ago
okay, basically the issue that's causing bug 210910 affects the potential fix
for this as well (crappy collapsing from context events).

-> 0.9 (waiting on the rewrite of the widget code)
Target Milestone: --- → Firebird0.9
(Assignee)

Updated

14 years ago
Keywords: polish
Priority: -- → P4
Target Milestone: Firefox0.9 → Firefox1.0beta
(Reporter)

Updated

14 years ago
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0-
(Assignee)

Comment 7

14 years ago
everything else is now double-click, so this isn't a major inconsistency any more.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 8

14 years ago
My main beef had nothing to do with inconsistency within Firefox, but
inconsistency between Firefox and Windows.

An icon in the status bar is not a common thing, in fact I find no reference to
one in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08d.asp
 but (as I indicated in comment 4) it exists in MS Word (spelling/grammer icons)
and in Windows itself as the system tray.

These icons generally do three things: provide a tooltip on mouseover, provide a
menu on right-click, and open a dialog or something similar on double-click.
They do nothing upon single left-click.

If "everything else is now double-click" then the style-switcher icon is still
inconsistent: upon double-click it opens the menu and immediately closes it.

I'm pretty sure that every widget in Windows that performs an action on single
left-click has a mouseover state, like highlighting a button (quicklaunch in the
Windows taskbar is an example). I believe the current behavior of the
style-switcher icon is bad UI.

Comment 9

14 years ago
THis should be revisited, esp. with the RSS icon context menu & the popup icon
context menu on the branch/preview release.

First of all, people assume that right click on this type of icon opens a menu,
as in the system tray.  Someone might try to right click, I'm thinking the
"power user" type person, and find that there's no menu there and that you can't
show a blocked popup, that you can't add the URL to an allow list, etc.  It's
bad discoverablity.

Secondly, this right click behaviour would be fine and even expected if the
icons had hover effects like normal toolbar buttons do, but as of now there's no
indication that you might want to click on them.

(BTW Mike, what do you mean by "everything else is now double click, so this
isn't a major inconstancy"?)

Comment 10

14 years ago
By "but as of now there's noindication that you might want to click on them."

I guess I mean kind of how the component bar on Mozilla suite statusbar acts
when you hover over the buttons and also press down on them.
(Assignee)

Comment 11

14 years ago
neither of those have context menus, so your comment has little merit.  Also,
given that the stylesheet switcher is currently hidden, I don't think there's
much of a point in revisiting it.

I don't think there's enough of a standard anywhere to say what the guideline
is, and guessing at what users expect without real usability testing is
guesswork at best.  I would actually suggest that most users are unfamiliar with
right-clicking anything.

As for the "everything is double-click" I made that comment after we made all of
the items respond only to double-click, its since returned to single left click.  
(Reporter)

Comment 12

14 years ago
As I mentioned in comment 8, and as the new commentor meant to say in comment 9:
in Windows, all items that respond to single left-click either have a hovered
state (either a button or a menu), or look like a link (underlined).

Menus, obviously, pop a menu. Buttons cause some kind of action, but don't pop a
menu. The only exceptions I know of are buttons with an arrow (like the back
history) and the Windows Start button.

Icons (which the status bar *icons* most resemble) perform no action on
single-click (except possibly highlighting), a non-menu action on double-click
(dialog, etc.), and pop a menu on right-click.

If these icons will not respond to right-click, they must have a hover state so
there is indication that they are clickable (turning them into [IMHO] weird,
menu-popping buttons).

More status bar icons have been added since I reported this bug. To me, this bug
refers to all the status bar icons, and I am changing the summary to reflect this.
Summary: Stylesheet switcher icon should respond to right-click → Status bar icons should respond to right-click
(Assignee)

Comment 13

14 years ago
You're not making a cohesive point.  Either you want: 

a) to have feedback on hover (aside from the tooltip, which I believe is
probably the most appropriate/least intrusive mechanism for these items, which
are equal part interface and notification)
b) have double-click + right-click (although the actions would not be the same).
Assuming users will figure out that the menu interface that we've implemented
would be on right instead of left click is silly, as is advocating a
dialog-based interface for these options on double click.

a) is vastly preferable, but I believe unncessary.  I think you're following the
"its not a or b, so it must be C" approach, discounting the concept that its
more of a Q.

This isn't taking a known, common UI principle, let alone a documented one, and
turning it on its head.  Its combining a notification area and a per-site
settings interface into a lean interface.  On Windows and GNOME, the closest
thing to this is the system tray, where most items respond to single left click,
with only a tooltip to indicate action, if there even is one.  And even in the
systray, there isn't a standard of any sort.

Last, this bit of UI is meant to be unobtrustive and slightly below the radar
most of the time.  This means that hover effects etc are not necessarily
desirable, unless the user is explicitly hovering on the item.  So in that
context, the tooltip is the best UI, which is why we did it in the first place.
(Reporter)

Comment 14

14 years ago
(In reply to comment #13)
> b) have double-click + right-click (although the actions would not be the same).

No, different actions. This would make sense for the popup icon: Right-click to
quickly change settings and double-click to bring the popup "Allowed Sites"
dialog. The security lock should bring up the security tab of page info on
double-click but doesn't need a menu. The RSS and style switcher don't have a
dialog interface (but might in the future) but use a menu to perform quick
operations.

> a) is vastly preferable, but I believe unncessary.  I think you're following the
> "its not a or b, so it must be C" approach, discounting the concept that its
> more of a Q.

My point was that the only interface elements in Windows which pop a menu upon
left-click have a hover state.

> On Windows and GNOME, the closest
> thing to this is the system tray, where most items respond to single left click,
> with only a tooltip to indicate action, if there even is one.  And even in the
> systray, there isn't a standard of any sort.

I can't speak for GNOME, but on Windows every systray icon I have on my system
does *nothing* on left-click. It has a tooltip on hover explaining what it
is/does. It might pop a menu on right-click. It might open a dialog on
double-click. It might do both. Nothing on left-click. I've seen some software
that violated that principle in the past, but haven't seen any single-left-click
behavior in the Windows status bar in years.

> desirable, unless the user is explicitly hovering on the item.  So in that
> context, the tooltip is the best UI, which is why we did it in the first place.

I really doubt that was "why we did it in the first place." The tooltip was put
in place primarily so people would know what the icons are supposed to indicate,
not directly to alert the user that the icons are clickable.

(Assignee)

Comment 15

14 years ago
> I really doubt that was "why we did it in the first place." The tooltip was put
> in place primarily so people would know what the icons are supposed to indicate,
> not directly to alert the user that the icons are clickable.

Er, it was done this way to be less obtrusive, yet still provide info to the
user if they hover on it.  Its not meant to be a "HEY, CLICK ON ME GUYS" interface.

Anyway, you're not saying anything new here, you're just repeating yourself with
different words.
(Reporter)

Comment 16

14 years ago
You responded to the new commentor, leading me to believe that this bug was open
for discussion. I didn't reopen the bug even though I think my argument is
better than yours. In my opinion, you keep repeating the same bad argument too;
I don't think we're going to agree here. It's your decision and not mine.
(Assignee)

Comment 17

14 years ago
My bad for responding to bug comments.

The original bug was that right-click should have the same action as left-click.
 I think I've stated a number of reasons why this doesn't make sense/have
precedent in actual statusbar controls.  The rest is offtopic noise that really
doesn't apply to this bug.  All other arguments aside, there is very little in
the way of standardization in the way of statusbar controls in Windows apps. 
They're a different animal from your examples, and since there's no real
standard, we can adapt to use whatever we feel is the best interface for the
intended action.  Dialogs certainly aren't it.

Updated

12 years ago
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → menus
You need to log in before you can comment on or make changes to this bug.