click-and-hold on folder in toolbar opens contextual menu

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Bookmarks & History
P4
minor
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: Andy Lyttle, Assigned: Mike Pinkerton (not reading bugmail))

Tracking

Trunk
mozilla1.0
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5+) Gecko/20011031
BuildID:    2001103117

When you click-and-hold on a folder in the toolbar, a contextual menu pops up on
top of the folder menu.

Reproducible: Always
Steps to Reproduce:
1. Create a folder on the Toolbar
2. Click-and-hold on the folder.  The folder's contents are displayed in a menu.
3. Keep holding for another second.

Actual Results:  A contextual menu appears on top of the folder menu.

Expected Results:  A contextual menu should not appear here.

Click-and-hold normally brings up contextual menus, in addition to control-click
or right-click.  That functionality should be disabled on toolbar folders (but
should still work on bookmarks in the toolbar).  Click-and-hold behavior applies
to Mac OS and Mac OS X only (AFAIK).

Comment 1

16 years ago
Confirming using Mac/2001112011, but I'm not sure what the right way to handle this is.

In truth, this is one of the worst-case problems of click-hold contextual menu access, in 
that two menus are displayed for the user as a result of a single click.

Personally, I think that, since real contextual menu access (control-click by default) is 
available on all Mac OS versions Mozilla supports, we should disable click-hold access 
permanently to avoid these sorts of conflicts.

In the meantime, my bug 107433 will provide a workaround.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

16 years ago
you missed your whole point! :-)

you don't disable click+hold globally - Mac users depend on it. You simple
enable turning it off where it is inappropriate. marking depends
Depends on: 107433

Comment 3

16 years ago
That's one interpretation, Claudius, but maybe not the best one.

Mac users don't depend on click-hold. They may be used to it, but they don't
depend on it.

What I'm suggesting is that coddling the kludge that click-hold has always been
causes more UI confusion than it satisfies legacy accomodation concerns. Things
will be more straightforward and understandable if we consign this practice to
the ash heap of history than if we don't.
(Reporter)

Comment 4

16 years ago
I would like an option in Preferences to disable click-and-hold globally.  I
personally use it from time to time, even though I do have a three-button mouse,
but obviously not everyone does, and it can get in the way.

Disabling click-and-hold globally is NOT the appropriate solution to this bug,
since click-and-hold works fine in most other places, and users (especially
those with one button) expect it.  I suggest disabling it on bookmark folders -
for the user that prefers click-and-hold, they can still access the contextual
menu with a control-click, and there's nothing terribly important in there anyway.

Bug 107433 (option to disable click-and-hold globally) is a workaround, but this
shouldn't depend on it.

Comment 5

16 years ago
I read 107433 incorrectly. I was actually dreaming about a bug that should be
asking for the ability for a feature owner to turn off click+hold on a per menu
basis by design. The main example is of course the bookmarks menu.
No longer depends on: 107433
I see the same problem sometimes when selecting items from <select>'s in
fill-out forms, if I hold the mouse button down too long (I'm usually thinking,
which can take a while).  The contextual menu just floats until the page reloads
or I select something innocuous like 'Select All'.  The menu should at least
disappear on mouse-up.

I didn't see a more general bug to reflect claudius's dream patch, should this
be it?
(Reporter)

Comment 7

16 years ago
What are some other places where right-clicking brings up a contextual menu, but
click-and-hold should not?

Option menus in forms come to mind, and click-and-hold is ignored there.
-> pink
Assignee: ben → pinkerton
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0

Comment 9

16 years ago
Dupe of bug 105244?
(Reporter)

Comment 10

16 years ago
Bug 105244 complains of click-and-hold opening a contextual menu for anything in
the personal toolbar.  This bug specifically refers to folders in the personal
toolbar.

Either 105244 is invalid (there's nothing wrong with click-and-hold on bookmarks
opening a contextual menu; in fact that's exactly what should happen), or this
is a duplicate of 105244 but the description of 105244 needs to be revised to
apply only to folders.

Comment 11

16 years ago
*** Bug 122535 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
nsbeta1+ if we can fix it
Keywords: nsbeta1+
(Assignee)

Comment 13

16 years ago
i'd like to get to this, it shouldn't be hard to check for a |container|
attribute, but if it doesn't make beta, it won't be the end of the world.
Priority: -- → P4
(Assignee)

Comment 14

16 years ago
*** Bug 105244 has been marked as a duplicate of this bug. ***
I think that just removing context menus from personal toolbar folders is the
wrong answer. Click-and-hold is problematic in many places in the app, not just
on personal toolbar folders.

The code seems to be too aggressive at bringing up a context menu even if I've
let up on the mouse. Happens in the browser, mail/news (clicking on mail
folders/messages), etc.

So, here's an experimental patch that does two things:

o  increase the click-hold-down mouse button time (from 1/2 sec to a full
second) so that the user is less prone to see the context menus unless they
really desired one;  waiting for a full second for a contextual menu to appear
doesn't seem to be too painful

o  abort the context menu from popping up if the mouse button was released
before the timer fires
Created attachment 73830 [details] [diff] [review]
Patch

Increase to 1 sec the time that a user must hold down their mouse button to get
a context menu to appear, and abort the context menu from appearing if the
mouse has been released when the timer to create it fires
(Assignee)

Comment 17

16 years ago
what your fixing is an event starvation problem with timers after pav landed his
time rewrite, nothing really to do with the conflict between right-click and
click-hold on toolbars. I think we should fix that the right way (smfr has the
bug), not just increase the time to 1 second. 

how does this patch address the fact that toolbar folders have both a click-hold
(drop down menu) and a context menu action?
(Reporter)

Comment 18

16 years ago
Increasing the delay isn't really the correct solution; click-and-hold is a
convenience for those with only one mouse button and having to wait a full
second would make the feature MUCH less convenient.  However, aborting the
contextual menu if the mouse button has already been released is definitely a
much-needed feature; if the system is low on RAM and virtual memory is swapping
like mad, it's very easy to get contextual menus popping up with jsut a brief click.

My thought on the conflict of two actions (dropdown and contextual): 
click-and-hold should do a dropdown menu, control-click should do a contextual
menu.  Contextual menus aren't absolutely required (folders are manageable via
bookmark manager) (and in fact must not be required according to Apple's OS8
HIG).  I think users will figure it out; I don't see any good alternatives. 
Should be documented as an abnormality though.
As I mentioned, this was an experimental patch.  :)

It doesn't deal at all with the fact that toolbar folders have both a
click-hold, (drop down menu) and a context menu action... and I don't see why
they can't have both, if implemented properly.

As for having to wait a full second for a context menu making the feature MUCH
less convenient than having to wait only a half second... right, sure, ok,
whatever.  YMMV.  :)

Having context menus appear inappropriately all over the app is the big thing to
try and fix, I think... thus the tweak to abort the context menu if the mouse
button was released.

Comment 20

16 years ago
Isn't this a dup of bug 117589? It it relates speficifically to toolbars, then
it should be re-summarized as "Toolbars should not show context menus".
(Assignee)

Comment 21

16 years ago
Comment on attachment 73830 [details] [diff] [review]
Patch

simon landed the StillDown() part. this patch is now obsolete. the original
problem remains.
Attachment #73830 - Attachment is obsolete: true
(Assignee)

Comment 22

16 years ago
Created attachment 76617 [details] [diff] [review]
check for a toolbarbutton that is a container

add one more check for when we shouldn't show the context menu: a toolbarbutton
that is a container (as folders on the personal toolbar are).

need r/sr. this one is pretty braindead.

Updated

16 years ago
Attachment #76617 - Flags: review+

Comment 23

16 years ago
Comment on attachment 76617 [details] [diff] [review]
check for a toolbarbutton that is a container

r=brade
(Assignee)

Comment 24

16 years ago
Comment on attachment 76617 [details] [diff] [review]
check for a toolbarbutton that is a container

sr=blake (from irc)
Attachment #76617 - Flags: superreview+

Updated

16 years ago
Attachment #76617 - Flags: approval+

Comment 25

16 years ago
Comment on attachment 76617 [details] [diff] [review]
check for a toolbarbutton that is a container

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
(Assignee)

Comment 26

16 years ago
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 27

16 years ago
VERIFIED Fixed with 2002040408 8.5 build
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.