To provide these properties: 1. After holding button 1 down for 250ms, the menu opens 2. The menu closes if button 1 is released while still over the menubutton 3. The menu also opens if a different button is used

If you're looking to copy the 4.x menubutton style, then you don't want #2 to happen. In 4.x, once the menu opens due to the delay in #1, you can release the mouse button anywhere you want and the menu remains open.

I say no no no, the current menubuttons are excellent, easier to use, smaller, everything. Even if you implement the binding, I still don't want people to use it in the chrome.

this is navigator's domain...

Dean, thanks for pointing that out. (Also my delay is too short). Fabian, thanks, but classic dual buttons have got bigger, not smaller.

Should the summary of this bug be "holding down back/forward should drop down history list", or does it cover other things as well?

Changing summary to make this bug easier to find on queries. (I'm assuming that (3) was either right-clicking on the button or clicking the arrow next to it, both of which already work, and I'm treating (2) as a detail of how (1) works.)

Hmmm, marking nsbeta1- and future. Don't think Ben will be touching this any time soon.

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

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

See also bug 90783, All dual menubuttons should respond to right-click.

This bug is a duplicate of a bug which was marked INVALID or WONTFIX (I forget which) back in 1999. I can't find it at the moment.

Ok, it appears that the bug I was thinking of was bug 39487 (and it wasn't 1999, it was 2000). See in particular the comments between 2000-05-18 and 2000-09-11. I think this bug should be wontfixed now for the same reason the idea was rejected then; it results in inconsistent behavior depending on whether you hold down the button for 0.249 seconds or 0.250 seconds.

As Dean pointed out, the patch that I provided, although opening the menu when you held the mouse button down, didn't stop the click action, unlike how as 4.x did.

wontifix

Trudelle: This is a 4xp bug with two dups and a patch, and neil pointed out that mpt's objection is really an objection to 4.x's implementation. You should at least give a reason if you're going to wontfix a bug.

Sorry, I thought it was obvious from the wontfix recommendation. MPT and I are as one on this, as has been discussed to death in other bugs and on the moz UI newsgroup. These were bad UE in 4.x, and the new implementation is also flawed in that it still presents as a button, yet acts like some strange combination of a button and a menu. This is not discoverable or predictable for the user. If you want to come up with some new widget that combines these behaviors usefully somehow, be my guest. Until then, lets keep buttons and menus as users expect them, or extend them only in ways that don't alter their button-ness and menu-ness. Resolving as invalid this time, because current behavior is not a defect.