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.
Re-assigning to Menus and confirming.
Severity: minor → trivial
Status: UNCONFIRMED → NEW
Component: General → Menus
Ever confirmed: true
QA Contact: asa → bugzilla
its not a context menu though, however I don't see a big problem implementing this -> taking
Assignee: blake → mpconnor
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
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 → ---
> 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
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
Priority: -- → P4
Target Milestone: Firefox0.9 → Firefox1.0beta
15 years ago
Flags: blocking1.0? → blocking1.0-
everything else is now double-click, so this isn't a major inconsistency any more.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → WONTFIX
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.
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"?)
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.
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.
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
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.
(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.
> 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.
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.
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.
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → menus
You need to log in before you can comment on or make changes to this bug.