107433 - Make it possible to turn off click-and-hold contextual menu access

Status: RESOLVED FIXED

(Core :: XUL, enhancement, P2)

Description

[Greg K.]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

A preference should be added to allow Macintosh users to disable click-hold
contextual menu access

Reproducible: Always
Steps to Reproduce:
N/A.

Actual Results:  N/A.

Expected Results:  N/A.

Other, standard, methods now exist on the Mac platform to access contextual
menus, such as the basic control-click.

There are situations where clicking and holding summons an unwanted contextual menu.

Comment 1

[Greg K.]

Assigning to Pinkerton per his request in n.p.m.mac.

Comment 2

[Greg K.]

This should probably be limited to Mac OS versions that implement systemwide 
contextual menus. I don't recall offhand when they were introduced (9.0?), but will find 
out and amend.

Comment 3

[:deanis74]

Someone's already written this.  See attachment 41135 [details] [diff] [review], which is attached to bug
49844 but is really for bug 89308.  It contains some code for Windows as well,
but it has the pref work in there.

Comment 4

[Raphael Schweikert]

Attachment: Multiple open folders in the Personal toolbar

when you click long on a folder in the personal toolbar, the contextual-menu
will appear and when you close it, the folder is still open and you can open
other ones. They stay open, even if you switch to another app. This doesent
happen, if you open the contextual menu with the ctrl-key.

Comment 5

[Mike Pinkerton (not reading bugmail)]

"Multiple open folders in the Personal toolbar" is really bug 108470. except for
one page where smfr pointed out that the webpage uses click-hold in dhtml, the
other complaints here are all individual bugs that we should just fix rather
than go round and round arguing about turning this off. *shrug*

Comment 6

[Matthew T (active 1999-2002)]

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

Comment 7

[Jo Hermans]

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

Comment 8

[Mike Pinkerton (not reading bugmail)]

fffffffuture

Comment 9

[Jo Hermans]

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

Comment 10

[Jerry Talkington]

This is extremely annoying.  The menu pops up when selecting <select> items, and
at other inopportune time, sometimes making you select an item before dismissing
the menu.

Comment 11

[Jerry Talkington]

Yuckola.  This stuff is peppered thougout the code with
#ifdef CLICK_HOLD_CONTEXT_MENUS
which is only defined on MacOS.  However, it's pretty cinchy to add a pref to
turn it off, and just check it before all the other checks in
nsEventStateManager::CreateClickHoldTimer.  I'll attach a patch.

Comment 12

[Jerry Talkington]

Attachment: Add the accessibility.clickAndHoldMenu pref to turn off click-and-hold context menus

Comment 13

[:deanis74]

Comment on attachment 138300 [details] [diff] [review]
Add the accessibility.clickAndHoldMenu pref to turn off click-and-hold context menus

I'm not advocating this pref, but if you want to implement something like this
it's better to replace the #IFDEFs entirely with the pref.

Comment 14

[Juha-Jarmo Heinonen]

This whole "hold mouse down to display the context menu" -feature should be considered a bug:
 - It's annoying
 - There are already a better way to do it (control-click / right-click)
 - It breaks sites where mousedown is used to move layers
 - It's a reminiscent of the Netscape Navigator "feature"
 - Safari uses control/right-click.

Comment 15

[Greg K.]

Jerry, does your patch still work? You'll need to request review if you want to
see it checked in.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[:deanis74]

(In reply to comment #15)
> Jerry, does your patch still work? You'll need to request review if you want to
> see it checked in.

See my comment 13.

Comment 18

[Jo Hermans]

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

Comment 19

[Asaf Romano (gone)]

Taking

Comment 20

[Asaf Romano (gone)]

Attachment: patch

Comment 21

[[e-mail]]

Comment on attachment 185390 [details] [diff] [review]
patch

I don't see the point of tracking the pref, as you really only need to read it
when creating the timer; KillClickHoldTimer only kills created timers ;-)

Comment 22

[[e-mail]]

Comment on attachment 185390 [details] [diff] [review]
patch

I'm also not a big fan of that choice of pref name but then my choice of
ui.click_hold_context_menu is somewhat boring too...

Comment 23

[Simon Fraser [no longer active]]

(In reply to comment #14)
> This whole "hold mouse down to display the context menu" -feature should be
considered a bug:
>  - It's annoying
>  - There are already a better way to do it (control-click / right-click)
>  - It breaks sites where mousedown is used to move layers
>  - It's a reminiscent of the Netscape Navigator "feature"
>  - Safari uses control/right-click.

Have you done any usability testing? Feedback we get from Camino (which doesn't
have this feature) is commonly that "context menus are broken". For many people,
this is the only way they know to get at context menus.

Comment 24

[Asaf Romano (gone)]

Attachment: patch v2

Comment 25

[:deanis74]

Comment on attachment 190331 [details] [diff] [review]
patch v2

>+  PRBool bClickHoldContext = PR_TRUE;
>+  bClickHoldContext = nsContentUtils::GetBoolPref("ui.click_hold_context_menus",
>+                                                  bClickHoldContext);

This is going to check the pref every time.  What happened to using an
observer?

Comment 26

[jhp (no longer active)]

Comment on attachment 190331 [details] [diff] [review]
patch v2

Well, I guess if we want to actually have a pref for this, then this code looks
fine.

Comment 27

[Jesse Ruderman]

See also bug 301758, which asks to disable click-and-hold context menus by default.

Comment 28

[[e-mail]]

Comment on attachment 190331 [details] [diff] [review]
patch v2

>+  PRBool bClickHoldContext = PR_TRUE;
>+  bClickHoldContext = nsContentUtils::GetBoolPref("ui.click_hold_context_menus",
>+                                                  bClickHoldContext);
>+  if (bClickHoldContext)
It seems to me you can write this in one statement i.e.
if (nsContentUtils::GetBoolPref("ui.click_hold_context_menus", PR_TRUE))

Maybe find someone suitable to make a ruling on observing the pref and follow
up as necessary?

Comment 29

[:deanis74]

(In reply to comment #28)
> Maybe find someone suitable to make a ruling on observing the pref and follow
> up as necessary?

Neil, I missed your earlier comment about not needing to track the pref.  Just
seems to me that context menus can be used a lot so we wouldn't want to read the
pref every time.

Comment 30

[Asaf Romano (gone)]

Attachment: as checked in

We need this on branch for bug 301758

Comment 31

[[e-mail]]

Comment on attachment 217659 [details] [diff] [review]
as checked in

I Don't really think I'm a module owner here...

Comment 32

[Asaf Romano (gone)]

MOZILLA_1_8_BRANCH
Checking in content/events/src/nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v  <--  nsEventStateManager.cpp
new revision: 1.595.2.17; previous revision: 1.595.2.16
done
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.585.2.29; previous revision: 3.585.2.28
done