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

RESOLVED FIXED in mozilla1.8.1alpha2

Status

()

P2
enhancement
RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: bugmail, Assigned: mano)

Tracking

({fixed1.8.1, platform-parity})

Trunk
mozilla1.8.1alpha2
PowerPC
Mac OS X
fixed1.8.1, platform-parity
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Assigning to Pinkerton per his request in n.p.m.mac.
Assignee: hyatt → pinkerton
Summary: Enable users to disable click-hold contextual menu access → Enable users to disable click-and-hold contextual menu access on Mac OS
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
(Reporter)

Updated

17 years ago
Summary: Enable users to disable click-and-hold contextual menu access on Mac OS → Enable disablement of click-and-hold contextual menu access on Mac OS
(Reporter)

Comment 2

17 years ago
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

17 years ago
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.

Updated

17 years ago
Blocks: 108470

Updated

17 years ago
No longer blocks: 108470

Comment 4

17 years ago
Created attachment 76398 [details]
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.
"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

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

Comment 7

16 years ago
*** Bug 163287 has been marked as a duplicate of this bug. ***
fffffffuture
Target Milestone: mozilla1.1alpha → Future
Keywords: pp
QA Contact: jrgm → sairuh

Comment 9

16 years ago
*** Bug 177021 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

16 years ago
OS: Mac System 8.5 → MacOS X

Comment 10

15 years ago
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

15 years ago
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

15 years ago
Created attachment 138300 [details] [diff] [review]
Add the accessibility.clickAndHoldMenu pref to turn off click-and-hold context menus

Comment 13

15 years ago
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

14 years ago
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.
(Reporter)

Comment 15

14 years ago
Jerry, does your patch still work? You'll need to request review if you want to
see it checked in.
*** Bug 258504 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago
(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

14 years ago
*** Bug 294743 has been marked as a duplicate of this bug. ***
Taking
Assignee: pinkerton → bugs.mano
Status: ASSIGNED → NEW
Priority: -- → P2
Target Milestone: Future → mozilla1.8beta3
Status: NEW → ASSIGNED
Summary: Enable disablement of click-and-hold contextual menu access on Mac OS → Enable disablement of click-and-hold contextual menu access
Created attachment 185390 [details] [diff] [review]
patch
Attachment #138300 - Attachment is obsolete: true
Attachment #185390 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #185390 - Flags: review?(jhpedemonte)

Comment 21

14 years ago
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 ;-)
Attachment #185390 - Flags: superreview?(neil.parkwaycc.co.uk)

Comment 22

14 years ago
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...
Attachment #185390 - Flags: review?(jhpedemonte) → review-

Comment 23

13 years ago
(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.
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
Created attachment 190331 [details] [diff] [review]
patch v2
Attachment #185390 - Attachment is obsolete: true
Attachment #190331 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #190331 - Flags: review?(jhpedemonte)

Updated

13 years ago
Summary: Enable disablement of click-and-hold contextual menu access → Turn off click-and-hold contextual menu access
Summary: Turn off click-and-hold contextual menu access → Make it possible to turn off click-and-hold contextual menu access

Comment 25

13 years ago
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 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.
Attachment #190331 - Flags: review?(jhpedemonte) → review+

Comment 27

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

Comment 28

13 years ago
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?
Attachment #190331 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

Comment 29

13 years ago
(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.
Created attachment 217659 [details] [diff] [review]
as checked in

We need this on branch for bug 301758
Attachment #190331 - Attachment is obsolete: true
Attachment #217659 - Flags: approval-branch-1.8.1?
Attachment #217659 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1?(neil)
Blocks: 301758
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.8beta4 → mozilla1.8.1alpha2

Comment 31

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

I Don't really think I'm a module owner here...
Attachment #217659 - Flags: approval-branch-1.8.1?(neil)
Attachment #190331 - Flags: approval-branch-1.8.1?(bzbarsky)
Attachment #190331 - Flags: approval-branch-1.8.1?(bzbarsky) → approval-branch-1.8.1+
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
Keywords: fixed1.8.1

Updated

10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.