Build: 2001092008, Mac OS 9.1 To reproduce: 1. Visit a few pages in a Navigator window. 2. Hold down the mouse on the Back button. What happens: * The Back menu opens. What should happen: * The Back menu should not open, unless the mouse button was held down on the menu part of the button. This causes two problems. If the mouse button is held down on the button part of the menubutton, it makes it appear as if releasing the button will do nothing (since no menu item is selected), when it actually goes back one page. And if the mouse button is held down on the menu part of the menubutton, the window stops responding to the keyboard completely.

Is this perhaps a Mac-specific bug? I can not reproduce this with 2001-09-28-21 on Linux, using the Modern theme.

This _is_ mac-only. The "back" dropdown menu is actually set as the context menu for the back button. As a result, click-hold brings it up. This is identical to 4.x behavior on Mac, by the way (not that that's a defence). Ccing pinkerton who I seem to recall implemented this.

Vaguely (ir)relevant: In 4.x for Windows, the back/forward context menu could be obtained either by right-clicking or holding down the left mouse button.

also a problem under os x (just making that note sorry for the "spam")

this is a dupe of a bug blake already has that the dropdown is set up as the context menu. buttons don't have context menus. that's terrible UI. fix that and this bug goes away.

All of the toolbar buttons had context menus in classic and they all will when we have toolbar customization in mozilla. We should get used to it. Well, they did and will on Windows anyways. We can disable this behavior on Mac if desired (apparently it is). Although mpt seems to be complaining only about the fact that the menu appears even when holding down the drop arrow, which is obviously incorrect and easily fixed.

No, I'm complaining about the behavior in general where holding down the button for 0.999 seconds will do one thing and holding down the button for 1.000 seconds will do something else. If you think Mozilla should have that behavior, go reopen bug 65726. While that bug remains invalid, however, click-and-hold should not open the Back or Forward menus.

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

This seems to be a duplicate of, or at least closely related to, bug 115223. The bad thing that happens (drop-down menu persists in background, stealing keyboard focus) is the same for both. For most people, this would be perceived as a crash, as the browser seems to quit (i.e., keyboard doesn't work). This is serious, and exactly the sort of bug that keeps me from recommending Moz to my dad, and other bug-intolerant people.

> If the mouse button is held down on the button part of > the menubutton, it makes it appear as if releasing the button will do nothing > (since no menu item is selected), when it actually goes back one page. Could we move the Back menu so that the first menu item is under the cursor? I think that would fix the problem.

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

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

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

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

This is causing Mozilla to appear to lock up completely, when click-and-hold opens a second copy of the menu and the first copy gets hidden behind the browser window. --> hang keyword.

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

Yes. The most annoying thing about this bug is not that the history menu opens. It's that it usually opens *BEHIND* the window and that the keyboard stops responding to input until you find this menu and close it. (Hitting the Escape key dismisses it.) This is a serious usability issue -- still present in Moz 1.2beta, Mac OS 9.x.

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

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

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

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

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

Changing OS-field to OS X, because OS 9 isn't supported anymore, but the bug still exists (see bug 208698). I'm using build 2003060503 on Mac OS X 10.2.6. The bug is now a bit different (see bug 208698), and doesn't cause a hang anymore (comment 15 and comment 17), because the keyboard is still working. What's happening is that you click-and hold the little button to get the pulldown-menu. But after a second, you'll notice that the pulldown will flash. Now, when you choose an url in that window, the window will seem to get stuck, and won't go away. You can make it go away by pressing the little button again. I think that by clicking-and-holding, you got the pulldown first, and the contextual menu secondly. This causes the flash, because a second (but identical) window is painted on top of the pulldown. When you make a selection (highlighting the url), the contextual menu will go away, but you're still stuck with the original pulldown menu (without the highlight). I think the solution would be to prevent the contectual menu to show while the pulldown is visible. Or close the pulldown menu when the contextual menu comes up (but that might trigger a few "double paint" bugs, because it causes a visible flash).

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.

Still happening (as described in comment 23) in Firefox 0.8.

(This bug made its way to Firefox but the problem exists in both FF and Seamonkey -- and presumably in Thunderbird menubuttons as well).

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

Not sure if this is the same bug or not, but I'm noticing on the July 15 nightly that when I bring up a contextual menu via right-click-and-hold, or left-click-and-hold, and drag down to the desired action (i.e. Close Tab, Back, etc.), that the menu hangs, and requires a second click to initiate the desired action.

Nope, this is a bit different than what I see (and still see). If you click (and hold) on the little down arrow in the URL bar (ie, about 3/4 centimeter left of the magnifying glass), that menu will pop up and will cause your URL bar to jump down at least a couple entries. It's difficult to explain, but just click on the down arrow and hold for just a second...

The only thing that remains a problem with this is that the pop-up menu isn't transient. I click on the back button for 3/4ths of a second and the pop-up menu comes up and then stays up. I have to click on another button or hit Escape to cause it to leave. On the other hand, it doesn't pop-up behind the application, hang it, or do other weird UI transmorgifications anymore.

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

It is still a problem in 1.0. However, the behavior is a bit different from what is written in the initial report. If you click and hold the big forward/back arrow itself a menu is displayed and then without letting go the button you have to choose the page and let go the button. Letting go the button without choosing anything from the menu causes Firefox to go back just one step. Therefore, FF handles well this type of situation. However, if you click the little menu arrow near the big back/forward arrows FF will display a menu (still correct). The problem is that when you choose a page and click in the displayed menu, FF will take you to this page, but the menu will not disappear. To sum up the bug in 1.0 is the menu not disappearing after a page has been selected. I would suggest changing the title of this bug.

Screenshot of my original error in action.

Clearly, my original bug (225727) that got merged incorrectly into this bug is still outstanding. There are two issues, as far as I can see: 1) Holding down the back or forward buttons results in a menu that won't go away. 2) Holding down the arrow for the history results in both a detached history list, and a menu that won't go away. I have attached a screenshot of the error so that it can perhaps stop being bounced about. It's still in version 1.0, hopefully it can be fixed by the big 1.1 Mac version.

moving blocking1.0mac bugs to Firefox1.1 Target Milestone.

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

The first problem I see here is that click-and-hold has WAY too short a timeout, and it's applied in too many cases. Not all Mac OS X objects with menus even implement click-and-hold as an activation mechanism... icons on the desktop, for example, require control/right click. I think Firefox really needs to limit or even eliminate click-and-hold on OS X. It's not implementing it in a way compatible with native widgets, and a lot of Mac related bugs would go away if you didn't have menus coming up at the drop of a mouse.

Josh, do we need to fix this, or is the current impl ok for DP?

Lets fix it. Its not OK.

(In reply to comment #37) > I think Firefox really needs to limit or even eliminate click-and-hold on OS X. > It's not implementing it in a way compatible with native widgets, and a lot of > Mac related bugs would go away if you didn't have menus coming up at the drop of > a mouse. That's bug 107433.

This patch fixes the problem by simply disabling click-hold. Bug 107433 is for adding a pref to enable/disable click-hold. I don't think that is necessary at all, I'd rather see it just disabled. Its buggy, and we don't need to add to the prefs bloat situation. However, we can leave the code in for developer reference in the future. So, this fixes this bug, and I recommend closing 107433 bug as WONTFIX. This should definitely be off for Deer Park.

Comment on attachment 189291 [details] [diff] [review] fix v1.0 I'm going to work on the pref patch later today, and pref it off (in another bug) for toolkit apps.

i just want to warn you of the impending backlash if you do this. not that i disagree, just prepare yourself well.

(In reply to comment #41) > So, this fixes this bug, and I recommend closing 107433 bug as WONTFIX. Well, we have at least one app in the tree which wants it to be turned on, seamonkey.

I strongly recommend not disabling click-hold menus. For many less experienced users, this is the ONLY way they know to get context menus. They have one button mice, and they don't know to press the control key. You will get streams of regression bugs that "context menus no longer work" if you do this. We still get them for Camino.

This should be fixed. Click-hold is used all throughout OS X and I see no reason why Firefox shouldn't be a good OS X citizen and use this functionality. Having it makes the program *much* easier to use and much more intuitive. I use one-button and multi-button devices and prefer the one button / click-and-hold. I also agree that you will see oodles of "context menu is broken" type bugs if you this becomes a WONTFIX.

(In reply to comment #46) > This should be fixed. Click-hold is used all throughout OS X and I see no reason Uh, pardon? From the Apple Human Interface Guidelines for Aqua: "Pressing and Holding Pressing means holding down the mouse button while the mouse remains stationary. Pressing by itself should have no more effect than clicking does, except in well-defined areas such as scroll arrows, where it has the same effect as repeated clicking, or in a Dock tile, where it displays a menu. For example, pressing a Finder icon should select the icon but not open it." While I'm admittedly new to *using* a Mac as my primary machine, I quickly checked all of the apps that shipped with OS X 10.4 (ie: Finder & iLife) and was only able to find two examples of a UI element which used click-hold to invoke a context menu: the first is a dock tile (which is the exception stated in the HIG) and the second is Safari (see note below). Can you give some examples of other apps that behave this way? Is this a change in the OS X behaviour as of Tiger? (note: Safari uses click-hold to get the history drop-down on its back/forward buttons, but that seems to be different from the behaviour of Finder, and just a workaround (that violates Apple's own HIG) to make up for the fact that they don't have compound drop-down buttons.) I tend to agree with Josh's recommendation in comment 41, and with reporter: the drop-down for back/forward should only appear when the drop-down part of the button is clicked, and everywhere else we should be following Apple HIG on how to respond to click-hold events.

I wrote this as Mike Beltzner wrote his, so there is some dupe info: I thought a lot about this today, and in the end I'm sticking with my opinion that click-hold should be gotten rid of. The only app I can find on Mac OS X is the dock, and that isn't really an app the way most users think of apps. None of Apple's iApps or Mail, for example, use click-hold. So I don't think dropping click-hold is going to make us less mac-like - if anything, the opposite. Simon's argument about having click-hold be the only way people know how to get context menus with a one button mouse is a good one, but I think it is flawed. Feel free to correct me, but if click-hold is not standard in Mac OS X apps, then how would people who are actually that novice even find out about it? Seems to me its more likely that they'll figure out the standard way to get context menus than they'll experiment with holding the mouse down in Firefox in particular. What do these people do in iTunes? If they didn't know and actually tried this in Safari or iTunes (unlikely) and it didn't work there, are they really likely to try again in Firefox? So I don't think many people are in that situation. We will get a few angry people, regression reports, etc., but this seems like the right thing to do for technical and maybe even conformance reasons. We cannot keep everyone happy. We have to make this call, and I think me (a Mac Mozilla developer), Beltzner (a Mozilla UI person), and mconnor (a Firefox peer), are a qualified group. Of course, drivers can always override. If anyone disgrees, please say so here. Beltzner and mconnor: if you agree, lets get reviews and request approval for my patch. (Seamonkey can ifdef it on if they like, I never suggested removing the implementation code)

(In reply to comment #48) > Feel free to correct me, but if click-hold is not standard in Mac OS X apps, > then how would people who are actually that novice even find out about it? Both Netscape 4 and IE on Mac have click-hold behavior. For those who've used the web since the early days on Mac, this is what they've grown up with. Still, it's your call.

Apologies for rehashing an old argument, but I disagree with Simon's and Martyr's earlier comments: https://bugzilla.mozilla.org/show_bug.cgi?id=102330#c45 and https://bugzilla.mozilla.org/show_bug.cgi?id=102330#c46 respectively, in that the behaviour isn't contextual at all. Contextual info is only there in single-button devices with the addition of a modifying key. These menus don't work that way. The problem is more akin to Apple's introduction of 'Sticky Keys' in OS 8 or 9; also click-hold menus are a rarity in OS X and are mostly seen in finder actions than in applications. Mike, Josh and Simon's final comments seem perfectly right - it's a mac platform bug on a platform that has changed substantially since this was acceptable behaviour for a widget.

Comment on attachment 189291 [details] [diff] [review] fix v1.0 I would rather see this wrapped in an #if 0 block so that embeddors can easily find and re-enable if needed, unless we're removing the entire impl. r=me on disabling this.

Comment on attachment 189291 [details] [diff] [review] fix v1.0 I will wrap it in an "#if 0" when it is checked in. Tough call, but I think this is best.

(In reply to Josh Asa, comment #48) > (Seamonkey can ifdef it on if they like, I never suggested removing the > implementation code) Fork core parts isn't a good plan, especially if xulrunner-seamonkey is stil in their todo list.

I feel strongly that we are making a serious mistake with this major UI change that will confuse the physical habits of any longtime mac browser user... hell, I've been using ffox on mac for about three months and the only way I know to open a link in a new tab is to click-hold the link. Let's fix the problem in a much more targeted way (fix the context-menu-in-context-menu problem) rather than hitting this with a UI cannon.

As I understand it, while the issue was originally just the back/forward thing (click-hold acts both as a single-back *and* a show the drop-down action) it expanded to cover the fact that: - the implementation is buggy (see comment 37 and comment 41) - click-hold to get context menus is non-standard for OS X - click-hold to get context menus isn't used in PC/Linux (and thus non-standard for the browser itself) Assuming that Mac users interact with other applications, they should be familiar with the standard way to get a context menu (ctrl+click or right click).

Furthermore, the default Mac OS X browser (Safari), used by most of the people who are novice enough not to know how to get context menus, does not support click-hold context menus. We are not "hitting this with a UI cannon" - this is just the time to get rid of click-hold, and this bug happens to be when we want to do it. This isn't the first time we've considered getting rid of click-hold. It isn't about just this bug.

Sure, it's not the first time, and it's not the last time, and we should reject it every time, at least until powerbooks come with two mouse buttons. The mac HIG is not the controlling concept here, it is the physical memory of our users: click-hold context menus are a long-standing behavior that was inherited from NS4 -> mozilla -> firefox and we shipped ffox 1.0 with it. That makes the change a major UI cannon regardless of the bugs that it may fix. Unless somebody is able to come up with empirical usability testing showing that the vast majority (more than 95%) of users do not use click-hold context menus, we should not simply treat this as a given "match the HIG" kind of change, but rather as the truly revolutionary change that I believe it is.

I'm all for supporting muscle memory, which is why I'm saying we should support the HIG definition of what to do with click-hold actions in the OS X UI. That's what HIGs are for: to make sure that all apps on a platform interpret certain UI actions the same way. We currently *do* support ctrl+click for context menus, which is the OS X way of dealing with the one-mouse button issue. If you want to say that click-hold is a nice optimization beyond that, then it should be a nice optimization available for *all* platforms and we should treat it as such. Otherwise we end up in a situation where we're supporting a UI gesture that is not standard either within the target platform or across all target platforms. Boo. Apple's got this thing about single-mouse buttons being simpler, and they've got their own way of dealing with context menus. (Your suggestion of a usabiltity test is interesting, but to be a fair analysis of the issue, it should be with *all* OS X applications, not just our browser, and ask users if they find one mechanism more convienient than another.)

Apple has 1-button mouses to this day largely because context menus are bad UI to rely on. On operating systems that have 2-button mouses, context menus can get very out of control, sometimes containing hundreds of items. Just wanted to make that clear. As for the physical memory of our users... Firefox is one of the ONLY apps on Mac OS X that uses click-hold, which isn't very conducive to training physical memory for context menus on the whole. It is doubtful that users are not aware of other ways to open context menus as Firefox is probably not the only app in which they want to use click-hold menus. In your case, you'd have figured something else out if they didn't exist. I get along just fine using context menus on my PowerBook, and I don't use click-hold. Why? Because I use the rest of Mac OS X in the same way. Aside from the fact that I use a standard way to access context menus, click-hold (waiting to be able to do something) is really a slow way to operate. It is a bad habit worth breaking if you can figure out an alternative. As for your specific PowerBook case... notice that you can only have 1 hand on the trackpad at a time. Nobody uses 2 hands to do that. Normally your other hand is free to be on the keyboard, conveniently over the control button that brings up context menus. It makes perfect sense how this works on a PowerBook from a physical space angle, and it is much faster.

Josh and Mike, if we were making a clean-slate decision, I agree with everything you said. If we had not already released years of mozilla and ffox 1.0 I would say absolutely, go ahead. But we have, and I believe a not-insignificant number of users have ingrained ways of doing things with our browser. With an established application, I believe that past history trumps both the HIG and idealism any day.

Safari, like Firefox, and the late MSIE/Mac before it, and NS4 before that, has click-and-hold menus for the Back and Forward buttons. So if you abolish such menus everywhere you'll just be replacing one bug with another. And if you abolish them just for links, you're not addressing this bug at all.

(In reply to comment #61) > Safari, like Firefox, and the late MSIE/Mac before it, and NS4 before that, > has click-and-hold menus for the Back and Forward buttons. So if you abolish This goes back to the original intent of the bug, I think, and I'm not actually arguing against removing click-and-hold as a mechanism of getting to the drop-down menu on the back/forward buttons, since (as you mention) every other mac-based browser does this. I'd be fine with (for back/forward buttons) single click = one step, click-and-hold = show drop down, and when drop-down is shown, if no entries are selected then nothing happens. What I am saying we should get rid of, however, is click-and-hold acting as a way of invoking the context-menu anywhere within the window. Perhaps this bug really needs to be forked: this one to deal with click-and-hold for back/forward, and a new one to deal with click-and-hold as an alternate route to the context menu.

Caveat: At work (with my Powermac G5) I use a two button mouse most of the time, and mostly on Windows. I do use Mac a fair bit though. Now, - At home (with my other Powermac G5) I use a Apple bluetooth wireless mouse, and it's convenient not to have to push the Ctrl button to open a context menu while browsing. It makes me feel faster. - You can argue about the merits of making those functions exposed in the context menu easier to do in other ways, but I don't see that these use cases have been identified or resolved. - What Benjamin said. Not just wrt 1.0, but other browsers on the Mac since the dawn of creation. Mike - your argument that other apps don't do this isn't 100% applicable here, because most other apps on OS X don't make extensive use of the context menu. You could argue that that's a flaw with the browser's UI (and I'm sure Matthew will) but if that's the case, then we need to come up with some other solution for those functions.

When I originally reported this bug, I assumed that we would eventually return to a world where men were men, buttons looked like buttons, and the button and menu parts of a menubutton were obviously different things, so clicking on the button part would act like a button whether you clicked it for 0.99 seconds or 1.01 seconds -- reliability over simplicity. In Safari (and Mail 2.0) buttons look like buttons, but (as in NS4 and MSIE) the button and menu parts of a menubutton are not different things, so (as in NS4 and MSIE) click-and-hold is appropriate -- simplicity over reliability. In Firefox the menu and button parts are separate, but they don't look separate, *and* the button part acts with click-and-hold, which is (IMHO) the worst of both worlds. If retaining the current appearance+behavior, the way to fix this bug is to make click-and-hold apply just to the button, not to the entire menubutton.

I use drag lock with my touch pad on my Powerbook (and iBook before that). I'd just be happy if holding a click on the scroll widgets of the Mail message window didn't invoke a contextual menu. (Should this be a seperate bug?) Control-click works there too.

In any case, I recommend taking this off the blockers list.

(Can we move the forever discussion to a new bug?)

(In reply to comment #67) > (Can we move the forever discussion to a new bug?) Done. See bug 301758 for the great "should we support click-and-hold context menus everywhere?" debate! I'll add this bug's cc list to that one.

Comment on attachment 190157 [details] [diff] [review] patch for the bug itself Hmm, this didn't seem to fix either issue for me, when I applied the patch. It seems like it should fix the issue of click-hold on URL bar arrow displaying both the history and the toolbar context menu (but it didn't fix it for me). But I don't see how this patch would fix the original issue of click-hold on back arrow showing history, and also going back when releasing mouse button.

Comment on attachment 190157 [details] [diff] [review] patch for the bug itself OK, so this patch gets rid of the double-menus when doing a click-hold on the menu part of the back/forward buttons. Cool. But it still doesn't address the first bug in the summary, that of going back one page when releasing the mouse. That should be fixed in this bug, too.

Since this bug is already useless enough, i moved the remaining issue to bug 302098.

Checking in nsEventStateManager.cpp; /cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v <-- nsEventStateManager.cpp new revision: 1.592; previous revision: 1.591 done

Verified fixed, Deer Park Alpha 20050810, OS X 10.3.9. > other apps on OS X don't make extensive use of the context menu. You could > argue that that's a flaw with the browser's UI (and I'm sure Matthew will) FWIW, Ben, I won't; I stand by the INVALID resolution of bug 34357.

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

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

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

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