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

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P4)

Description

[Andy Lyttle]

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

[Greg K.]

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.

Comment 2

[Claudius Gayle]

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

Comment 3

[Greg K.]

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.

Comment 4

[Andy Lyttle]

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

[Claudius Gayle]

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.

Comment 6

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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?

Comment 7

[Andy Lyttle]

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.

Comment 8

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

-> pink

Comment 9

[Chris Lyon]

Dupe of bug 105244?

Comment 10

[Andy Lyttle]

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

[John Morrison]

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

Comment 12

[saari (gone)]

nsbeta1+ if we can fix it

Comment 13

[Mike Pinkerton (not reading bugmail)]

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.

Comment 14

[Mike Pinkerton (not reading bugmail)]

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

Comment 15

[Robert John Churchill]

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

Comment 16

[Robert John Churchill]

Attachment: 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

Comment 17

[Mike Pinkerton (not reading bugmail)]

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?

Comment 18

[Andy Lyttle]

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.

Comment 19

[Robert John Churchill]

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

[Simon Fraser [no longer active]]

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

Comment 21

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 73830 [details] [diff] [review]
Patch

simon landed the StillDown() part. this patch is now obsolete. the original
problem remains.

Comment 22

[Mike Pinkerton (not reading bugmail)]

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

Comment 23

[Kathleen :Brade]

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

r=brade

Comment 24

[Mike Pinkerton (not reading bugmail)]

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

sr=blake (from irc)

Comment 25

[Asa Dotzler [:asa]]

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

Comment 26

[Mike Pinkerton (not reading bugmail)]

fixed.

Comment 27

[Claudius Gayle]

VERIFIED Fixed with 2002040408 8.5 build