301758 - click-and-hold shouldn't be interpreted as right-click

Status: RESOLVED FIXED

(Firefox :: General, defect, P2)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 1

[Asaf Romano (gone)]

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

Comment 2

[Josh Aas]

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.

Comment 3

[Uri Bernstein]

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=

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

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).

Comment 6

[Josh Aas]

"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!

Comment 7

[Asaf Romano (gone)]

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).

Comment 8

[Gary Elshaw]

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.

Comment 9

[Zach Lipton [:zach]]

> 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. 

Comment 10

[Josh Aas]

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.

Comment 11

[Gary Elshaw]

(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.

Comment 12

[Zach Lipton [:zach]]

With my Shaver quote (fyi Gary, Shaver is a member of [e-mail], 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. 

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 15

[Jesse Ruderman]

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

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

(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. 

Comment 17

[Matthew T (active 1999-2002)]

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).

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 19

[Asa Dotzler [:asa]]

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

Comment 20

[Mike Connor [:mconnor]]

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

Comment 21

[Asaf Romano (gone)]

The fix for Bug 107433 is now on trunk.

Comment 22

[Asaf Romano (gone)]

Attachment: Turn it off for everything but seamonkey

Comment 23

[Asaf Romano (gone)]

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

Comment 24

[Scott MacGregor]

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

Comment 25

[Asaf Romano (gone)]

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).

Comment 26

[Karsten Düsterloh]

> 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". :-) )

Comment 27

[Chris Andrichak]

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.

Comment 28

[(not reading, please use [e-mail] instead)]

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

Comment 29

[Adam Guthrie]

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

Comment 30

[Ryan Flint [:rflint] (ping via IRC for reviews)]

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

Comment 31

[Adam Guthrie]

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

Comment 32

[John Edgar]

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.

Comment 33

[j_chan]

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.

Comment 34

[Jo Hermans]

(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.

Comment 35

[Jo Hermans]

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

Comment 36

[Sidney Markowitz]

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.

Comment 37

[Stefan [:stefanh]]

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

Comment 38

[Kyle Rhorer]

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.

Comment 39

[Jon Evans]

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

Comment 40

[Mike Chomyk]

(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.

Comment 41

[P T Withington]

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.

Comment 42

[Arne]

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).

Comment 43

[Joel Craig]

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.

Comment 44

[Mike Chomyk]

(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.

Comment 45

[Arne]

(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'... :/

Comment 46

[Mike Chomyk]

(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.

Comment 47

[John Edgar]

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. 

Comment 48

[Wayne Woods]

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).

Comment 49

[K. Richard Pixley]

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.

Comment 50

[Stefan [:stefanh]]

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

Comment 51

[Per Olofsson]

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...