Closed Bug 159224 Opened 22 years ago Closed 21 years ago

Click and Hold Should Activate Context Menu

Categories

(Camino Graveyard :: Toolbars & Menus, enhancement)

Product:
Camino Graveyard
Component:
Toolbars & Menus
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: syrreg, Assigned: mikepinkerton)

References

Details

(Keywords: relnote)

Attachments

(3 files, 10 obsolete files)

clickholdtest.tgz
9.69 KB, application/octet-stream
Details
changed [self window] to NSApp
2.02 KB, patch
Details | Diff | Splinter Review
timer/callback
3.59 KB, patch
Details | Diff | Splinter Review
This is a problem/feature that most Mac users (those with a single mouse button) would probably like fixed/added, and it works fine in Mozilla: When a user clicks on a link without releasing the mouse button, a context menu should appear. This is functionally similar to getting a context menu by holding down the CTRL button while clicking on a link.
Component: Bookmarks → Toolbars & Menus
Target Milestone: --- → Chimera0.5
Ah yes, the infamous click and hold! ->pinkerton
no, really, ->pinkerton
Assignee: saari → pinkerton
we don't want this. click-hold isn't something we want to carry over to osx. it's not in the HI guidelines and two-button, 3rd party mice are prevalent. it also seems to cause more problems that it's worth given how we have to hack up gecko to get this to work.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I'm sorry but this is an extremely useful feature for 95% of the Mac users out there - how many iBooks and Powerbooks have more than one mouse/pointer button? None. How many desktop systems does Apple sell with mice that have more than one button? Same answer. So are you saying that anyone who wants to use Chimera as their browser should plan on coughing up some money to get a multi-button mouse? So much for the simplicity that comes with using a Mac. OmniWeb, IE and Mozilla all have some variation of this feature. Such a shame: a request for 1 step forward suddenly turns into 2 steps backwards. Oh well. Chimera is now turning into a nice looking, but counter-intuitive app. Anyone know of any Mozilla projects to build a nice looking, Cocoa type browser for people that actually use a Mac??
for starters, take your attitude down the road. nobody wants it here. also, click-hold is _not_ an apple-approved UI gesture. period. only a tiny number of apps support it, and that's only because NS4 instituted it did way back when before there were 2-button mice. the finder doesn't do it, msft apps don't do it, no apple app i know does it. are you going to complain to them about not being mac-centric developers?
No disrespect intended. You folks have done a lot. Just expressing disappointment.
*** Bug 159439 has been marked as a duplicate of this bug. ***
I took a look at the reference mentioned and on page 40 they refer to the Dock and Apple's use of the click-hold feature to invoke a menu: [http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGDock/index.html] "When a user presses and holds the mouse button on your application’s tile in the Dock, a menu appears." They even have a screenshot. This indicates the following: 1. Clicking and holding the mouse button (on a 1 button or multi-button mouse) on an object to invoke a context menu is an Apple approved gesture. Notice how they phrase it: "the mouse button" - they don't specify a left or right mouse button, etc. Why is that? It's because they assume that there is only one mouse button. 2. Apple has in fact implemented this functionality in one of their essential OS X applications, i.e. the Dock. This seems like it's a reasonable feature to request, especially since most people have come to expect and enjoy this behavior when using a Mac web browser. It's not like this is a request to make the browser transparent, or something silly like that. I find it very surprising that there is so much opposition to it from the Chimera/Navigator team. Can this bug be reoppened and flagged with FUTURE as it's Target Milestone instead of just killing it? Maybe one day someone will get around to implementing it? Thank you.
reasonable points
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
futuring and giving back to saari to get it off my list ;)
Assignee: pinkerton → saari
Status: REOPENED → NEW
Target Milestone: Chimera0.5 → Future
QA Contact: winnie → sairuh
I've taken to using 0.5 more often since many improvements have been made since the last release (new computer doesn't hurt either) and I must say the lack of a "click and hold" context menu is the one thing I'm really missing. While it may not be standard behavior across the board I think it's expected behavior in a Mac web browser. I'd hate to use IE as the comparative benchmark because it's a hideous OS X app is almost every respect. It won't keep me away from Navigator but it is something that makes OmniWeb or Mozilla a nicer product to use for most people, including myself.
Severity: normal → enhancement
I agree that this gesture is sorely missed, the dock gesture moves me. Plus, Apple violates their own UI guidelines regularly.
The HIG only defines context menus for the Ctrl-click combination. It's definitely easy to see that in many situations this makes sense (e.g. when you might drag instead). It's equally easy (to me) to see that sometimes it makes sense to also allow click and hold ... since the HIG doesn't mention that at all... To look at it from the other direction, will people ever click-and-hold and want something different to happen?
I can not think of what else someone might expect a click and hold to do in the browser. AFAIK, the only thing that click and hold has ever done besides provide access to context menus is that you have to click and hold for a moment in order to grab and drag the icon in the title bar of a Finder window and I do not see that being a point of confusion for anyone. IMO, it is extremely important to provide the traditional click and hold behavior in Chimera. Chimera is practically unusable for me on my Powerbook because it lacks the expected easy access to the context menus.
I tried out a hack of Phoenix that was posted by Kevin Gerich here: http://www.kmgerich.com/ misc.html . Click and hold to obtain context menu functionality is there just as it is in Mozilla proper and Netscape for Mac OS X. I really have no sense of exactly how difficult it is to implement this in Chimera, but since it already seems to be something available in embedded Gecko, can you folks turn it on? Also, can a pre-1.0 target milestone be assigned for this feature now? Even if it doesn't work perfectly at first, it would be better than not having it at all.
How about we not turn this on in Chimera until bug 107433 is fixed for those of us who don't like it?
Bug 107433 has been around for over a year and has a total of 3 votes; that does not indicate a very high demand. I do not belive that implementation of this common browser feature should be postponed by that bug.
I added my vote to this because my Mom and Sister both expect this kind of behavior. It isn't clear that it is an HIG violation or not, but it certainly is expected behavior in the user community-- of which, my Mom and Sister are excellent examples just plain users without an ounce of development background about them (though I did successfully walk my Mom through a session in the Terminal once).
This bug makes me want to vomit.
A lot of user community requests make developers cringe; why would anyone possibly want or expect the system to work in that fashion? Unless I'm mistaken, the whole point of this project is to serve the user community. The user community wants click-and-hold for the context menu. That request doesn't actually conflict with any developer / advanced user needs -- the feature is invisible if you don't use it. So what's the problem? Give the user's what they want unless you have a vastly better way of doing this.
I'm going to take exception to 'the feature is invisible if you don't use it' comment. Ever use Mozilla and get popups you didn't expect when clicking? It's especially bothersome in mail/news and is directly related to the hack for click&hold rather than requiring a control-click or secondary mouse button to initiate a popup.
I can't say that I have had that happen to me, but I can certainly understand how it could happen. How about a preference that defaults to enabled?
I just queried Bugzilla for all Chimera bugs with 10 or more votes; if I'm not mistaken, this Bug has the second highest number of votes. I don't know if the vote counts are considered important, but they seem to indicate that there is a significant desire among Chimera users to have this feature added. Is it resonable to request that this feature be prioritized (considering the number of votes it's recieved) and given a pre-1.0 Target Milestone? Thanks for your consideration.
until apple adds this to cocoa, it would be incredibly inconsistent for us to use click-hold w/in the content area and control-click outside the content. talk about confusion!
It has been pointed out that the Dock has click-hold menus, and this is one of our most-requested features. It's something that novice users expect, even if they don't use context menus anywhere else.
that's nice, the dock, the dock, the dock. anywhere else in the UI? Any support for it anywhere in the toolkit? Nope. I'm not rewriting every UI element in appkit to do this.
What about having it work just inside the content area.? I for one would find that better than the current situation.
Gerry, votes are an advisory. That's all. S. Woodside, there are enough people who don't want this at any cost to make it less than a no-brainer.
I understand Pinkerton's frustration regarding actual implementation; however that does not change the fact that other Mac browsers have the click-and-hold and thus users expect it. Although I have yet to see evidence that there are a _signifigant_ number of people who "don't want this at any cost" but as already been suggested, their complaint is easily addressed with a pref to disable the click-and-hold. I expect that if a poll were taken that the number of users who want click and hold easily outnumber the people who are vehemently opposed to having it. I do believe the need to fix this bug is indeed a "no-brainer" regardless of how many are opposed. If there is enough opposition to cause anyone to question the fact that this bug should be fixed, then the need for a fix for bug 107433 is a "no-brainer" as well.
"Click and hold on a link should activate context menu" functionality is certainly consistent with what users coming over from both IE and Mozilla (as well as OmniWeb and Opera) and any other Mac browser expect. At this point it's a convention. How can that be confusing if it's what users expect to happen? This bug was filed to have click and hold on a ** link ** invoke a context menu. Who wants this functionality in the rest of the UI? Someone can file another bug for that if they want (it won't be me). Users of other Mac browsers don't expect this gesture to work on bookmarks, toolbars etc., just links in the content area. P.S. - Greg, I don't know how you are quantifying "there are enough people who don't want this at any cost" to compare with those who are chomping at the bit waiting for it to work. Popular vote (and common sense) indicate that there are more people expecting this behavior (because they are used to it) than there are people that don't want it. There are more users with one button mice than there are with multi-button mice. Who the heck wants to buy and carry a multi button mouse around with their iBook or Powerbook or even to use with a desktop? I'm sure the majority would rather save the space or use the space for an extra battery.
"Users of other Mac browsers don't expect this gesture to work on bookmarks, toolbars etc., just links in the content area." Uhh, i'd bet they do. If it works that way in one area, it should work that way everywhere. "Popular vote (and common sense) indicate that there are more people expecting this behavior (because they are used to it) " Because the people who are ok with the way it is don't go out of their way to complain. That's why the internet is full of people complaining. BTW, this isn't a democracy. However, I digress. This discussion is off topic to the bug and is best discussed elsewhere.
A quick example of why NOT having this feature in a Mac web browser is more confusing for users than having it: http://www.maps.com/explore/downloads/usmap-1280.html Echoing comment #29: "the need to fix this bug is indeed a "no-brainer" regardless of how many are opposed."
Gerry, see comment 31. This is not, has never been, and will never be a "no-brainer." Please take the discussion elsewhere.
Where else should this bug be discussed if not here? This is Bugzilla. Discussing bugs on the Chimera listserv doesn't do any good because the developers rarely participate -- which is why I unsubscribed. So, if this isn't the place to discuss this bug, someone needs to _explicitly_ state what is a good place to discuss this bug.
> Click and hold on a link should activate context menu functionality is > certainly consistent with what users coming over from both IE and > Mozilla (as well as OmniWeb and Opera) and any other Mac browser expect. > At this point it's a convention. For what it's worth, Apple's own Safari browser does not support click and hold for context menus. Recommend marking as INVALID. Sorry for the spam.
3 points: 1) Safari is a beta browser from which many functionalities are missing at this point, so click and hold might show up later.2) When you click and hold on the "Back" button, you see a list of the previous pages you visited, so that makes yet another example of Apple using the click and hold method in one of their own interfaces.3) In order for Chimera to remain relevant and to differentiate itself from Safari, it might be useful to add the features requested by users instead of imposing useless restrictions. Improvement and Innovation are the keys to making viable software.
This is easy to do by adding a MouseDown method and a timer. In ContentClickListener.mm, add a MouseDown method that sets up a timer that waits for a MouseUp event. If the timer fires before a MouseUp is received, then do what MouseClick does but with button = 1. If the MouseUp comes first, go to MouseClick without any changes. Give the users 1 second, that's what the dock and IE give.
No, I'm wrong. The popup menu is actually handled in CHClickListener, not in ContentClickListener. They really should be merged, but whatever, it's too complicated, there's obviously lots of magic going on in netscape code to control who's getting the events. Forget about that. Here's how to do it. In BrowserTabViewItem, in the implementation for BrowserTabItemContainerView, modify - (void)mouseDown:(NSEvent *)theEvent to add a timer /there/ ... if the timer fires before mouseUp is received, then send on theEvent and set some state to be checked in the MouseUp handler. If the state is true, modify the mouseUp event to be a NSRightMouseUpMask, that will fire the handler in CHClickListener instead of the one in ContentClickListener.
this sketches out what I'm talking about
Attached file clickholdtest.tgz —
standalone pbproject demonstrating the click-hold principle i'm working on.
Attached patch clickHold2.patch (obsolete) — — Splinter Review
Patch to BrowserTabViewItem.[h,mm] that should turn a click & hold that last longer than 1 second into a rightclick event before it hits the gecko code that decides what to do with the click.
Attachment #113311 - Attachment is obsolete: true
what happens if you click and drag? do you start dragging then get a context menu?
I have not looked at the code, but can't you just have a mouse move nullify the timer?
->pink
Assignee: saari → pinkerton
re comment 42 : yup, that's not going to work. i'm hacking on it now but it's got some irritating complexities.
Attached patch clickHold3.patch (obsolete) — — Splinter Review
Try this one. It should cancel the popup if the user drags before they popup timer fires. I also changed rightMouseUp to rightMouseDown, and removed some code that was left in my from my testapp.
Attachment #113325 - Attachment is obsolete: true
Attached patch clickHold4.patch (obsolete) — — Splinter Review
forgot to change the other rightMouseDown (in the event)
Attachment #113455 - Attachment is obsolete: true
It appears I'm editing the wrong view. Is there a summary somewhere of which of the layered views do what? TIA
I've got a patch now that does this on my build, i'm going to live on it for a while to make sure it works OK. The code goes in the same place as the Cmd-Opt dragging code in that bug's patch, so they might collide (?) but I have them both working together on my local build.
I've got this running on the latest CVS. It works OK. Note that this patch may collide with the patch in Bug 150297.
Attachment #113456 - Attachment is obsolete: true
Removed "on link" from the summary, because this applies to everything within the browser view, not just links.
Summary: Click and Hold on Link Should Activate Context Menu → Click and Hold Should Activate Context Menu
There's a fairly serious conflict with Manfred Schubert's PDF plug-in. I suspect that the plug-in is passing MouseDown messages to the nsChildView but not passing the relevant MouseUp or MouseDragged messages. Thus, the context menu always fires interfering with the use of the PDF plug-in.
Added inline documentation about how it works. Fixed an issue causing a crash if ctrl-key and click-hold context menus were both used. Still have the issue described with the PDF plugin (but it's not as bad now and non-crashing).
Attachment #114966 - Attachment is obsolete: true
I don't think I have the behaviour quite right. In the dock, if you click and hold and then let go, the context menu stays up. I'll probably try to get this to work that way as well (so it's not just a one-hand operation, but a one-finger operation!)
I am unable to fool the gecko-ish code into thinking it's received both a rightMouseDown and a rightMouseUp, because the rightMouseDown call blocks until the context menu operation is complete. I /don't/ want to get into spawning a thread to do it, that just leads to all kinds of unnecessary nastiness. Now I'm trying to figure out how (and, like, where is the code?) gecko handles context menus. Wish there was some documentation...
Attached patch 159224-hold-7.patch (obsolete) — — Splinter Review
[This patch is cleaned up, without any beeps or debugging print statements] In order to implement click/hold context menu support, changes are made to the nsChildView.[h|mm] sources. The changes make modifications to the mouse event handling routings. The mouseDown event now creates a timer set to fire after 1.0 seconds, the delay time used by the OS X Dock. The mouseUp and mouseDragged event handlers cancel the timer immediately, otherwise, if no mouseUp or mouseDragged events are handled, then it is certain that the mouse has remained motionless for the entire duration of the 1.0 seconds. At this point, if the timer has not been cancelled, it fires, triggering a callback function. The callback function creates a new rightMouseDown event and sends it to self, i.e., the nsChildView object. This is a "spoof" event designed to fool the nsChildView object into thinking that the user clicked the right mouse button which, it is known, activates a context menu immediately. The rightMouseDown call is made to self, and it's preexisting behaviour is to block until the context menu is dismissed by the user. Once the context menu is dismissed, the callback returns, and normal operation resumes. RISK: minimal. no changes are made to the embedding or gecko code. the Cocoa API for timers is well known and operates in a predictable fashion. There is no concurrency in this implementation. it is expected that a rightMouseDown event will continue to generate a context menu indefinitely. there is little chance of the basic Cocoa API for handling mouse events to change. PERFORMANCE IMPACT: None - O(1). The code path only executes on a mouseDown, there are no loops, NSTimers are highly optimized, and the code to create the rightMouseDown event only executes if the timer fires. INTEGRATION NOTES: The click/hold code need not be the first to evaluate in the various mouse event handlers; it will work correctly so long as it is evaluated before the embedded calls are made at the end of the respective functions. TESTING: Tested on my system for several days. Tested in the "Longship" build by a number of community members. Testing included tests of using the ctrl-click combination intersperced with the click/hold technique. USER EXPERIENCE IMPACT: Should be positive. the feature is already present in Mozilla for Mac os x and Internet Explorer for Mac OS X. It is also present in the System Dock. TODO: The menu would be better to stay open when the user releases the mouse button over a non-context-menu-entry zone. This is the behaviour in the Dock/Mozilla. I investigated implementing this trivially (e.g. passing a NS_MOUSE_RIGHT_CLICK instead of NS_MOUSE_RIGHT_BUTTON_DOWN in the rightMouseDown handler) without success. Further investigation in terms of tracing the execution path of mGeckoChild->DispatchMouseEvent(geckoEvent) is needed. This would involve code changes in the embedding code and thus more risk. Another bug should be filed as an enhancement to implement this behaviour.
Attachment #115021 - Attachment is obsolete: true
Heh... much simpler patch. This one uses ... nextEventMatchingMask:NSAnyEventMask untilDate:[NSDate dateWithTimeIntervalSinceNow:1.0] ... to simply wait a second and see if anything else comes along ... if not then it's a click-hold. I tested with PDF Plugin and it works fine.
Attachment #115357 - Attachment is obsolete: true
Attachment #116741 - Flags: review?(pinkerton)
Comment on attachment 116741 [details] [diff] [review] hold-8-159224.patch simplified, fixed problem with PDF plugin Not sure if pinkerton is around or seeing the review request.
Attachment #116741 - Flags: review?(pinkerton) → review?(sfraser)
it's on my list, and i'm still thinking about issues with interacting with gecko and if we really want it.
If you decide that you do not want it, can you at least allow the rest of us to have it? All that would need to be done is create a preference that is off by default. Make it a hidden pref if you feel the need, but please give us the option. This is one of the few issues that is preventing myself and others from using Camino as our default browser.
HI click hold is very useful with one-button mouse (and I like one button mouse. it's _simple_ ) omniweb use it very well. and I miss it. some applications made by apple use it, not everywhere. but in some place and it's really nice. not need to use a 2 button mouse. I think Camino should add that.
re comment 59 gecko issues -- it's a menu, so it's owned by the application not by the embedding code. It uses the same embedding code that is used by control-click. If you were to handle in embedding then embedding would have to know how to create a menu or use call-backs, I don't think you can have it both ways (since the timer).
Comment on attachment 116741 [details] [diff] [review] hold-8-159224.patch simplified, fixed problem with PDF plugin i played with this patch for a while, and even cranked the timer up to 5 seconds. if i clicked and held for more than just and instant, we sometimes wouldn't track selection and would pop up the menu...5 seconds later. something is just not right with nextEventMatchingMask. sometimes it works, sometimes it loses the events.
Attachment #116741 - Flags: review?(sfraser) → review-
I can't reproduce that. Can you give me a test case? How many times do you have to try it before it does the wrong thing? what kind of mouse are you using?
msft optical wheel mouse, happens probably 90% of the time if i click hold for more than just an instant and then try to drag.
Maybe the microsoft mouse fires the events in a different run loop. I changed the mode in nextEventMatchingMask to NSDefaultRunLoopMode. It works the same way as hold-8.patch on my system (TiBook with the touchpad).
Attachment #116741 - Attachment is obsolete: true
Attachment #124302 - Flags: review?(pinkerton)
Comment on attachment 124302 [details] [diff] [review] changed mode to NSDefaultRunLoopMode that's all this patch doesn't apply cleanly to the trunk. can you put up a new one?
Attached patch again (obsolete) — — Splinter Review
updated to latest trunk (pulled today, cvs updated nsChildView.mm 15 min ago)
Attachment #124302 - Attachment is obsolete: true
Attachment #124782 - Flags: review?(pinkerton)
i have the exact same problems with this new patch: holding the mouse for even the slightest of time and moving it won't cancel the click-hold and the context menu appears. am i alone here?
Comment on attachment 116741 [details] [diff] [review] hold-8-159224.patch simplified, fixed problem with PDF plugin It was in longship-2 (http://longship.mozdev.org/) downloaded 124 times. no one ever emailed me with any bug reports about click-and-hold.
Attachment #124782 - Attachment is obsolete: true
Attachment #124976 - Flags: review?(pinkerton)
Any news?
Does someone want to donate me a Microsoft mouse?
Attachment #124302 - Flags: review?(pinkerton)
Attachment #124782 - Flags: review?(pinkerton)
Please update, seems to be a really nice patch with already a big part of the code ready to go.
Comment on attachment 124976 [details] [diff] [review] changed [self window] to NSApp We have a new Camino request flag which can be set multiple times for a patch. Moving old review requests to the new flag. Sorry for the spam.
Attachment #124976 - Flags: review?(pinkerton) → review?
Ugh. If this is implemented, please make it an option. None of the non Moz browser have it, AFAICT, so it would cause confusion among new users. It's also very annoying if you have more than one mouse button. RE: comment #8, this is only implemented in the Dock, nowhere else. The dock is meant to be a one-click task switching application, so that makes sense. Most people would not expect it from a web browser, since IE and Safari don't implement it.
re: comment #76: Nope, OmniWeb and Internet Explorer both have click and hold context menus. Anyway, I happen to have a microsoft mouse and I've tried Longship with the patch enabled. It seems to work fine for me--I didn't notice any problems with dragging.
taking.
Status: NEW → ASSIGNED
Ender, would you mind providing the full details for your mouse. Make, model, any other kind of technically identifying information. Also, the exact details of any kind of driver you may have installed for it, and what operating system version you are running. Perhaps we can track down the trouble.
Comment on attachment 124976 [details] [diff] [review] changed [self window] to NSApp >+ [newMouseEvent retain]; //leak? necessary? Yes you leak.
i just tried this again with a regular apple mouse. here's what i did: - change the delay to 9 seconds. rebuild. - go to google.com - click the "Advertise with us" link and hold for 2 seconds. it should just click the link because it's less than the delay time, right? instead it locks the ui for 7 more seconds and displays a context menu. sbwoodside, can you reproduce this? i can do it 100% of the time with this setup.
Huh. I can't reproduce it on that link, or on any other link (although I'm getting google.ca not google.com). Can you try it on a different machine?
Attached patch timer/callback — — Splinter Review
try this one. it's a different approach, in this one, I fire off a timed message. if the callback is called and the event is still valid, then it activates the context menu. since this one uses event differently, maybe it will work.
this works for me. i checked and the event is retained by the system until after the callback fires. seems safe enough.
landed with cleanup.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
I think it should be 1.0 seconds. That's what both Mozilla Firebird and the Dock use.
Using the 2004011603 NB, I can get a contextual menu to appear when mousing down using the iBook's track pad. Works fine when mousing down on the pages content and/or the pages plugin content (flash, QT). Tested under 10.3.2.
It works as advertised, really cool. But isn't the time before it pops-up a bit long?
Attachment #124976 - Flags: review?
FWIW, this breaks PDF Browser Plugin since the (browser) context menu comes up if one drags stuff in the plug-in (scrollbar etc.)
sigh, i knew stuff like this would show up. please file a new bug and assign it to sbwoodside.
Blocks: 232314
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: