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).
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
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
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.
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.
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?
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.
Assignee: ben → pinkerton
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Dupe of bug 105244?
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.
*** Bug 122535 has been marked as a duplicate of this bug. ***
nsbeta1+ if we can fix it
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
*** 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
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?
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.
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 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
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.
Comment on attachment 76617 [details] [diff] [review] check for a toolbarbutton that is a container r=brade
Comment on attachment 76617 [details] [diff] [review] check for a toolbarbutton that is a container sr=blake (from irc)
Attachment #76617 - Flags: superreview+
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
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
VERIFIED Fixed with 2002040408 8.5 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.