Graduating this particular bone of contention into its very own bug to seperate it from the click-and-hold issue brought up in bug 102330. Background reading: bug 102330 comment 41 through 65 bug 107433 The facts: Since Netscape 4, the NS and Mozilla have used click-and-hold as a shortcut into the context menus to allow for a quick mechanism for single-mouse users on the Macintosh platforms. The Apple HIG, however, states that click-and-hold should be an equivalent operation to click, except for in certain circumstances (such as Dock tiles). Instead, Apple's recommended route to context menus is ctrl+click. Safari, Camino, Opera and IE 5 for Mac all use the standard ctrl+click to get context menus, and do not respond to click-and-hold. The only click-and-hold action in these browsers is on the back/forward buttons, to get the drop-down history (see bug 102330). Firefox supports both ctrl+click *and* click-and-hold. The debate: Removing click-and-hold will bring Firefox in line with the Apple HIG, but at the cost of removing a feature that many established Mac users may be very familiar with. Some (full disclosure: myself included!) feel that this change, while initially jarring, would be worth it in order to ensure that we are complying with the platform look-and-feel, and point out that all other Mac apps require ctrl+click, such as iTunes (for editing an ID3 tag), and indeed, it may be more jarring for users to discover that click-and-hold does not work as a shortcut to the context-menu in other applications. Further, the current click-and-hold implimentation is somewhat buggy. Others feel that the established user base would be very upset about this feature being removed, noting that ctrl+click is still there, and this is just a further optimization for one-mouse-button users. Buggy implementations should be fixed, not removed. That's about where we are.

Nominating for decision purpose, we should change it either by the upcoming release or never.

For assessing buginess, please put [click-and-hold] in the title of any bugs cause by click-and-hold context menus. Note that buginess is not the core reason for removing click-and-hold menus.

The following search query might be of some use (looks for open Mac bugs with "click" and "hold" in the summary): https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=click+hold&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=---&rep_platform=Macintosh&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

It needs to be noted that OS X states this because in general context menus are a bad idea from a UI point of view - they're hidden so people don't tend to think to invoke them unless they're trained to or are inquisitive/technical. As a result most MacOS X applications don't make heavy use of context menus. Browsers are slightly different however, the context menu almost always contains something useful and depending on what you're trying to do, holding down Ctrl can be a pain. Not all users have two button mice, and Powerbooks force a single button mouse setting. It should also be noted that in addition to historical implementation in Netscape browsers, other browsers (aside from Safari and Camino, which do not enable this feature) implement variants of this: IE5 (which was the dominant browser for the period of 2000-2003 on MacOS probably) implements a click-hold-drag function, and OmniWeb5 (based on WebKit like Safari) hand rolls Click-Hold to restore functionality its developers perceived as being missing in the standard Safari WebKit builds. You can argue that Safari and the growing number of Windows switchers mean that the historical set of users that rely on this feature are less important, but in general I am against removing features that are somewhat hidden, and by their nature are sticky, if there isn't a compelling reason to remove them. (e.g. performance, critical bugs, download size) At the very least, this is the sort of change you don't want to test on a final release, only on a beta (to gauge response), so marking blocking-aviary1.5- because if this doens't make 1.5b, it should not ship in 1.5b at all.

I'm not sure that OS X states that click-and-hold should be interpreted as identical to a click action *because* context menus are hard to discover. I'm pretty sure they state that because click-and-hold actions are hard to discern from a click-action without some well-agreed upon value for the "hold" time, and thereby lead to confusion. You mention that you're against taking out features that are well-hidden, and perhaps that's my real saw here. The feature isn't well-hidden. It pops up accidentally fairly frequently (especially on older hardware) and interferes with standard click-actions. (Anecdotally, but FWIW, I've been on a Mac Mini as my primary machine for two weeks now, and I've seen a lot of this) I'll buy that browsers have a lot of context-sensitive operations, but there are well-defined modifiers (ie: apple-click) and menu actions (ie: apple-u) to help people with but a single mouse button, ctrl+click included. I'm not sure why we're inventing another. On one thing I totally agree: testing in beta is a must, if we're gonna do this for 1.5 :) We do need to be careful on how we interpret the feedback, however, as nobody's gonna write in to tell us that they're glad it's not there anymore, or that they're happy we're behaving more like a OS X native app. (Final sidenote: MacIE 5.2 seems to have gotten rid of click-and-hold, but I'm not sure when that change happened).

"Browsers are slightly different however, the context menu almost always contains something useful" I disagree. My mother has no need to go into context menus. Everything a normal user needs to has equivelent functionality. And even if you insist that that isn't entirely true, just use the ctrl key. Its not that painful. It's a relatively simple way to access a lot of functionality for more advanced users, and its faster. And if you're more advanced, you'll be more familiar with using the keyboard and the mouse together. And if you're on a PowerBook, using the ctrl key is even more convenient because if you're using the trackpad, its right there under your hand!

FYI: http://www.macosxhints.com/article.php?story=20040810010357459 mentions that Shiira (a web-kit based browser) has implemented this too. Also, it looks like it's a desired behavior for Camino as well (see pinkerton's comments on bug 235794).

I've already made some comment on <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=102330#c50"> this</a>, but i'm glad to see the discussion evolve. Without trying to be too reductive, this debate seems to be coming from two different perspectives: Should Firefox conform to browser (albeit historical) or application norms. If you have followed anything coming from Apple HQ or Redmond in the last few years we all know IE is gone for the future, for the last two iterations of the Mac OS Safari has been the default browser. The last version of Mac IE came out on the 16th of June 2003 and Netscape 4 in, i believe, 1997. Personally, i believe internet year's are more than dog year's; and not only that, the usability of Apple's OS X HIG has solidified in the last 3 iterations of the OS to mean that a set of expected behaviours are there for users now. One of these is that there is no click-hold functionality for widgets/buttons. To be really brutal, this functionality makes me think of a 1997 intermediate kludge for users who hadn't quite got used to using the contextual menu in OS 8 or 9. I think we can all agree, that OS 8 and 9 was a very long time ago. Or another way to think of it, Mac IE is the last application on the mac, aside from Firefox, to use this 1997 behaviour - at all. By the way, does anyone know anyone using Netscape 4? Two proposals: Gauging from the discussion some people like this (ahem, reprehensible) functionality, so why can't we make everyone happy and make it a real function and make it part of the preferences eg: 'Enable click-hold on Back and Forward buttons' The other possibility is doing a poll via Mozillazine or whomever. I realise that this would be an enormous pain and not give a very wide or balanced perspective, especially for mom and pop users, but it is all part of my evil plan to make Firefox more accessible to the public insofar as features; and gives great PR, especially after this last week's quite negative announcements on Mozillazine. Or am I totally off my head? We could do a poll.

> Can't we make everyone happy and make it a real function > and make it part of the preferences eg: 'Enable click-hold on Back and Forward > buttons' No more UI prefs please. Just take one look at Seamonkey preferences and you'll see what I mean. UI's should just work, people shouldn't have to set preferences for things that they shouldn't even think about. > Am I totally off my head? We could do a poll. "Democracy is a shitty way to design software." -- Mike Shaver. Enough said. Ok with those comments out of the way: Yes this technically violates the Apple HIG. That being said, I do not consider the violation to be meaningful, in that if you conducted actual usability testing, I do not think that you would find that it would take any users longer to perform their browsing tasks with click-and-hold right-click enabled than with the feature disabled. In fact, it would take a small group of users longer with clik-and-hold disabled, as they would need get used to the change in behavior. The most compelling argument for removing click-and-hold is that it would allow us to comply with the "platform look-and-feel." Yet I think it's clear that removing this feature to follow this guideline provides neither consistancy (we already support ctrl+click so people who are used to that need not think about it) nor an improvement in usability (no-one would accomplish their task faster or with less difficulty if click-and-hold was removed). Furthermore, Apple uses click-and-hold in several places, including the Dock and in menus If we need to tune click-and-hold so doesn't pop up when it shouldn't, then lets do the testing and research required and fix the feature, not just take it out all together. Lastly, many websites (e.g. http://www.google.com/search?q=mac%20%22click-and-hold%22&sourceid=mozilla2&ie=utf-8&oe=utf-8) give instructions to mac users to "click and hold" when saving a link or image to disk. Users expect these instructions to work properly, and will end up spending their time trying to get click-and-hold to function, not knowing that we disabled the feature.

WRT comment #7 - AFAIK, this is not a desired behavior in Camino. It will not be coming back even if we could work the bugs out.

(In reply to comment #9) > Can't we make everyone happy and make it a real function > and make it part of the preferences eg: 'Enable click-hold on Back and Forward > buttons' Zach said: "No more UI prefs please. Just take one look at Seamonkey preferences and you'll see what I mean. UI's should just work, people shouldn't have to set preferences for things that they shouldn't even think about. " > Am I totally off my head? We could do a poll. Zach said: "Democracy is a shitty way to design software." -- Mike Shaver. Enough said." Ok, i can understand that putting one more preference option in might be considered annoying for some, but for others it provides something many perceive as value: choice. It also solves the problem of some individuals liking this feature (and i can definitely see why powerbook owners would like it), and others who don't like it because the UI already provides the tools to do the job that click-hold provides. Because Mike Shaver (not that it matters, who is Mike Shaver?) says something doesn't necessarily make it true. If it were true i doubt very much would get done unless that single developer or lead has a particularly authoritative or despotic view of function. Perhaps consensus is a better word in this case? Zach said: "Furthermore, Apple uses click-and-hold in several places, including the Dock and in menus" Yes, but Apple doesn't do this in its applications which should be the defining principle here. We could go on forever. I'll butt out now.

With my Shaver quote (fyi Gary, Shaver is a member of staff@mozilla.org, and while he is not a usability expert (nor am I of course), I certainly agree with him on this point), I was trying, perhaps unsuccessfuly, to say that UI decisions should be based on actual research, not on voting. Research is expensive of course and can't be applied to every situation, but I think the right thing to do here is for Beltzner and the UI team to figure out how better to optimize the feature so that it will not be activated by accident. I personally have never managed to trigger this feature by mistake, but it is clearly an issue, and as such, we should fix it, not throw the whole thing away.

small data point: I've had a Mac at home for five months now and I didn't know about ctrl-click (in any app). I did discover click-hold fairly rapidly*. The flip side of comment #5 is that click-hold is actually more discoverable. I'd certainly have been disconcerted if click-hold was suddenly and mysteriously removed. * I suppose that might be because I remembered fixing click-hold bugs in nsEventStateManager :-) Context menus may be bad UI in some absolute sense but switchers from other plaforms, like me, will appreciate them being there.

This is the sort of bug where comment is speculation. We should get some user testing.

See also bug 107433, which asks for a (hidden?) pref.

(In reply to comment #14) > This is the sort of bug where comment is speculation. We should get some user > testing. I'm not sure what the benefit of that would be in terms of coming to a resolution here. The debate is not whether or not there is an established user base who expects Firefox on Mac to respond to a ctrl+click. Nor is the debate really about which method (click-and-hold vs. ctrl+click) is a better way of getting context menus on MacOS [1]. The debate is about whether or not we should be making the default implementation of our application include a UI gesture that is non-standard for the target OS. I kind of see this like mouse gestures. It's a funky little UI optimization that some people may find useful, and is a good target for extension-land. [1]: technically, this is Apple's call. I've speculated (see comment 5) as to why they don't want click-and-hold to be interpreted differently than click, but the issue remains that that's what they say. Invoking a context menu is a desktop-wide UI gesture, and there's a well-documented way for OS X applications to do that. Us providing our own way makes us feel less like an OS X native application.

For posterity, this bug is the opposite of bug 18726. Apart from inconsistency (and being consistent with an OS that is generally becoming less internally consistent is lots of fun), the main argument against click-and-hold is that holding for x+0.01 seconds has a different effect from holding for x-0.01 seconds. Netscape 4 for Mac solved this brilliantly: if a normal click would have done something, the click-and-hold menu contained a default item to do the same thing (e.g. "Open this Link"), and the menu was opened with that default item already positioned under where the cursor had been when the hold began. For illustration, see attachment 13963 [details] (and the "niggly related detail" in bug 18726 comment 42).

As per email with Ben, and IRC discussions with mconnor and mano, I think what we want to do is: - get a patch that makes this a hidden pref, default = off - make it so that if the pref is turned on, it works on any OS - make a workaround for OS X so that click-hold invokes the drop-down menu on the back/fwd buttons, as we don't want to lose that functionality

if we get a low risk patch, we'll consider but not going to block on this.

Mano, when do you expect to have a patch for this?

The fix for Bug 107433 is now on trunk.

Scott, please comment whether this change is also desired for Thunderbird.

yeah I'm interested in it for Thunderbird to Asaf. Thanks!

Comment on attachment 217661 [details] [diff] [review] Turn it off for everything but seamonkey (I'm not sure who should a= this, but that's not really an issue in this case).

> there are well-defined modifiers (ie: apple-click) and menu actions > (ie: apple-u) to help people with but a single mouse button, ctrl+click > included. I'm not sure why we're inventing another. Because it's just *convenient* to just click and hold, without the need for a keyboard, the need for a second hand or the need of a second mouse button. Using a browser is all about being comfortable with the way of accessing information that actually isn't made for easy reception (reading is work! *g*), so why remove features that make things *easier*? Is software allowed to surpass its environment's usability? (Obviously not, it seems.) This features usefulness is bigger by far than the harm it does - so if you really need a pref for that (which I doubt), its default should be "on". (That said: I'm very content that the SM default is set "right". :-) )

Accessibility data point: Using a naturalpoint/smartnav (www.smartnav.com) head tracking mouse with its dwell clicking and dragging facility, I often have trouble with Thunderbird interpreting my drags as click and hold events, bringing up the context menu when I don't want it. The timing on my software for my head to tracking mouse is adjustable, but Thunderbird (I don't normally used fireFox) is the only application I have to this trouble with. Doing a control click is not a problem, the software allows me to set a modifier key for a click.

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

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

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

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

I downloaded Firefox Rc2 today from the mozilla website and I was pleasantly surprised with all of the new features, it is ergonomic, well designed, and over all a pleasure to use. Browsing around for 30 minutes or so, I clicked and held my mouse over a link and to my surprise nothing happened. On a mac system, this would normally open a context menu (right click for windows users). I thought the application was messed up so I removed it and reinstalled, same deal, I rebooted my system, started up firefox again, and nothing happened. I thought, weird. I checked all the preferences and couldn’t find anything regarding this feature I’ve counted on for so long. I couldn’t figure out what the heck was going on, so I did a little research on the problem and found this bug. I cannot even begin to express to you how utterly shocked and horrified I was when I learned that his feature had been removed. And even more disgusted when I read it was done in the name of “standards”. While I understand the need for standards. Deliberately HINDERING a user base in the name of standardization is absolutely ridiculously. This is a perfectly acceptable feature that goes a long way in improving workflow in the Firefox web browser. It allows for users to quickly navigate image properties, page source, etc etc. It is especially useful for those of us who are mouse orientated, and people like myself who use graphics tablets (Might I add a large portion of mac users are graphics orientated). This feature changes the usability of firefox in a negative way and hurts productivity. Removing a VERY well established and very well used feature because it is “not compliant” it not only counter-productive but also terribly rude to the user base. I will be very upset if this makes it into the final release of firefox.

I have to agree with the summary "click-and-hold shouldn't be interpreted as right-click." As per commenter #27, I ran into this with Thunderbird misinterpreting drag events as click-and-hold, and I was using a standard mouse! I hadn't noticed that Firefox had the same behaviour since I don't tend to drag much in Firefox. I also propose the "hidden" option in about:config, as the general trend seems to be options being removed from the preference UI. Since there seem to be people quite passionate about this on both sides of the fence, a preference seems logical whether it's hidden or not.

(In reply to comment #33) > I also propose the "hidden" option in about:config, as the general trend seems > to be options being removed from the preference UI. Since there seem to be > people quite passionate about this on both sides of the fence, a preference > seems logical whether it's hidden or not. > The option is already there : do to about:config and set ui.click_hold_context_menus to true. You might have to create it first, if the setting doesn't exists.

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

Like the author of comment #32 I was surprised by click-and-hold not working in Firefox 2.0rc3 when I downloaded it. Searching for what was wrong, I found this bugzilla issue. Unlike comment #32, I have no prolem with the change being put in. On the Macbook and Macbook Pro, at least, running Mac OS 10.4.8, I have the option in System Preferences, Keyboard & Mouse, Trackpad Gestures, of setting the trackpad so that having two fingers touching the pad when I click gives me the same result as control-click. That is even more convenient than click-and-hold to get a context menu, producing its result immediately with no chance of unexpected results from being slow at click and dragging, and no reaching for a control key. However, I think it is very important to put some mention of this UI change in the release notes as a known issue. Without some way of making sure that people know about the change, it will appear to be a bug and will confuse anyone who uses click-and-hold.

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

As a PowerBook user, I must say that I'm disappointed in the resolution of this issue. When I installed FF 2.0 and discovered that click-hold no longer brought up a context menu, my first thought was that it was a bug. Perhaps my Bugzilla searching skills are sub-par, but I did not find a bug report on the issue. I then thought that before I file a bug report, I should make sure there isn't a preference that got changed. Once I found out from filing the bug that there is a ui.click_hold_context_menus pref, I changed it and was back to normal. However, I *did* look through about:config before filing a bug report and, perhaps because I didn't know quite what terms I was looking for, managed to overlook it. I must agree with comment #36 that at the very least, there should be something in the release notes about this. Ideally, since so many people do use the feature and have come to depend on it, I think the pref should be visible in the normal prefs dialogue instead of hidden in about:config. I can live with the default being off but it should be easier for people newly upgrading to 2.0 (now that it's officially released) to find the pref to turn it back on. Just my newcomer's two cents.

Hi Kyle, (In reply to comment #38) > As a PowerBook user, I must say that I'm disappointed in the resolution of this > issue. When I installed FF 2.0 and discovered that click-hold no longer > brought up a context menu, my first thought was that it was a bug. Perhaps my > Bugzilla searching skills are sub-par, but I did not find a bug report on the MacBook user here. Right-click can be obtained by either using a multi-button mouse, or Ctrl-click, same as the rest of the OS. The problem with click-and-hold for right click is that the popup menu appears if you're dragging some text or an image to another app and you pause slightly after clicking. This happens quite a lot because it's natural to pause and glance over to the drag destination just before commencing the drag. You end up having to stop, cancel the menu by clicking, reselect the text, and start dragging again. Although click-and-hold is used in other places in Mac OS X (e.g. the Dock icons) it's actually a very rare behaviour. Jon

(In reply to comment #39) > Right-click can be obtained by either using a multi-button > mouse, or Ctrl-click, same as the rest of the OS. Yes, it can, very true but a lot of people want to operate the touchpad one handed as this is behaviour they have become used to with OSX. Let us also not forget that a lot of websites state that Mac users can save by holding down their mouse button over an image, and let us also not forget that this is behaviour ingrained into the Mac community. The issue here is not one of compliance with the OS as a whole but compliance with the expectations of the user. When every single iteration of Firefox so far has allowed hold-click where is the sense in making it a hidden, and badly abbreviated, featured in a page the average user, who this will affect the most, knows nothing about. I, for one, know that people have put off upgrading till this "bug" is fixed. If the feature is not going to be "fixed" then it needs to at least be pointed out to those downloading the programme for the Mac and expecting the hold-click behaviour to continue rather than just remain an obscure bug on a hard to find page that 99% of users know little to nothing about.

Another _satisfied_ Mac user here. I am _very_ happy with the way this bug has been resolved, since FireFox was the only app that perpetuated this 'click-hold for context menu' gesture, long after Apple phased it out. This is the correct fix. App's should not be inventing their own UI gestures. The UI gestures need to be uniform across all apps.

FWIW. PowerBook user here: extremely disappointed with disappearance of said feature. Upon noticing the absence of the 'hold left click' (or long left click) feature, I went searching in bugzilla for a bug, and was *very* surprised to find the *opposite* is now considered to be a bug. I don't see why it would be considered harmful to the application if feature would still be present: it seemed like very logical behaviour, in view of the absence of a right mouse button. > Right-click can be obtained by either using a multi-button > mouse, -snip- Will you buy me a two-buttoned trackpad? In favour of making this a configurable option (about:config).

Like the status change says, see comment #34, or if your portable is supported, install something like iScroll < http://iscroll2.sourceforge.net/ > which will give you 2-fingered contextual menus just like the newer machines. This bug is resolved, move on.

(In reply to comment #43) > Like the status change says, see comment #34, or if your portable is supported, > install something like iScroll < http://iscroll2.sourceforge.net/ > which will > give you 2-fingered contextual menus just like the newer machines. This bug is > resolved, move on. > I don't think the issue is, any more, of the presence or absence by default of the feature but merely the poor way in which the change was handled.

(In reply to comment #44) > (In reply to comment #43) > > Like the status change says, see comment #34, or if your portable is supported, It's not. So were does that leave moi? > > This bug is resolved, move on. Can't we reopen it? :/ > I don't think the issue is, any more, of the presence or absence by default of > the feature but merely the poor way in which the change was handled. For me it's still an issue, and I'm not the only one, appareantly (I found out, after actually reading most of the entries on this page). Also, is this issue in any way related to the sudden change in function of the 'backspace' button in FF for Linux? (it used to be 'move one element back in history, now it's 'move to top of the page when at the bottom'... :/

(In reply to comment #45) > For me it's still an issue, and I'm not the only one, appareantly (I found out, > after actually reading most of the entries on this page). Well the functionality is there, it's one change in about:config, it's just that the notification of this for Mac users is woeful. Perhaps an option in the Mac installer to turn it on or leave it off would suffice? That way there would be no clutter in the preferences/options dialogue, no need to trawl the about:config, just one checkbox that defaults to normal Mac behaviour but gives people missing the feature the option to have the older and more recognised behaviour.

For an organization that is trying to push forward in their customer service and build their user-base, telling a large population of mac users who feel this is a problem and should NOT have been removed (myself included)to stop whining and move on is not going to win any awards.

Regardless of whether the change was a good one, this bug is NOT the place for lobbying, suggesting new ideas, or arguing about it. Especially not to this extent. Follow-up comments on closed bugs should really only be for mop-up, or pointing to follow-up bugs and the like. If you have a suggestion that you feel will improve the situation (such as the one about making it easier for Mac users to access the preference to re-enable click-hold), then please file a new bug (if it doesn't already exist).

I think the choice to remove this as a default, but leave the functionality available was a beautiful choice. However... * the functionality is not easy to find - this should be in the preferences panel and * currently not available at all because it's not working.

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

In the classic "Me too!" fashion: I'm so happy I stumbled over this bug, as I also assumed that something broke between 1.5 and 2.0 after finding nothing about it in the release notes. A preference option would be great, or at least a mention of ui.click_hold_context_menus in the documentation. This 50-post comment fest with 7 dupes tells me that I'm not the only one missing it...