Back and Forward respond to right-click by dropping down their corresponding menus, but Get Messages (in mail) and Print and don't. See also bug 65726, holding down back/forward should drop down history list (dual menubutton).

-> XPApps

actually, i'd argue that none of them should respond to right click. the fact that it does that on back/forward is a bug that i filed and blake has. we need some UE input on this.

This isn't necessary in Classic and wouldn't be on Modern if the targets weren't so dang small.

it's 4xp in classic, and while i don't usually use it i'm not sure I see any reason not to implement it for classic.

I tried adding a contextmenu handler to dual menubuttons to drop them down instead of opening the context menu. I added event.preventBubble() and event.preventDefault() to the handler but it still opens the context menu :-(

i restate my objection to this from a UI perspective. buttons should not have right-click behavior.

I concur with pinkerton, the back and forward little menu buttons should not have right-click behavior. Marking p4, enhancement, and future.

Hitting those tiny arrows is a pain in the butt. I see them as a scourge of Mozilla's UI. NS4.x was fine with right clicking on buttons. Sheesh. In any case, it's inconsistent and it makes the package seem unprofessional.

We attempted to fix this problem by designing the combo button behavior to match that of Windows. However we ran out of time before. (See attachment) Toolbars in Mach V Modern may be undergoing some changes however, so we'll try to coordinate this with a new update to the theme

Thanks Marlon. The image seems corrupted, but if I read you right, it'll make things more like the windows classic theme. I won't state any opinions on that, other than I'm really interested in other planned changes for MachV. But back to the issue of this bug: Is everyone still against right-clicking on a button being the same as clicking on the little down arrow? Is it 4xp for this behavior to occur in mailnews? Combo-buttons in IE6 and windows explorer for XP all drop down their menus with a right-click.

right clicking or click-and-hold behavior is more desirable than using a combo button, in my opinion. but it all depends on what planet you come from (school of thought). It seems there has been some discussion on that topic in the past. Combo buttons are never easy targets, and they add space and clutter to the toolbar.

-> default assignee

Combo buttons can be easy targets, as in classic and other defacto standard implementations, or they can be nearly impossible bullseye targets, as in Modern. A reachable target is a usable affordance, not 'clutter'. Right click is not discoverable many users, so it isn't a sufficient solution. Click/hold is bad because the behavior changes due to an imperceptible time delta that may be a complete surprise. The only real-world button I know that works that way is the power button on my laptop, and even then only when the OS has frozen.

Well would it be better if the buttons always opened if you moused down on them, but closed if you moused up on the button itself (as opposed to the dragging down the menu)? This could also resolve the "Mark All Read" menuitem on the news "Mark" button being unavailable when no message is selected.

<p class=ot>the power button on my desktop at work is the same way, hold for 5secs to poweroff, otherwise it'll reboot</p>

Neil: I feel pretty strongly that a button should look and work like a button. For completeness, I think that menu titles that work like buttons (command menus?) are also bad.

> I feel pretty strongly that a button should look and work like a button. Sorry for any confusion but I was specifically talking about those dual buttons that have those down arrows to show that there's also a menu. I'm just suggesting that the whole button area could show the menu and permit the option of drag- selecting a menitem, rather than insisting that you hit the arrow although that gives you the advantage of keeping the menu open.

I wasn't confused.

*** Bug 125387 has been marked as a duplicate of this bug. ***

*** Bug 230326 has been marked as a duplicate of this bug. ***

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614