* TITLE/SUMMARY [4.xP] Long-click means of invoking contextual menus not supported * STEPS TO REPRODUCE 0) Launch Apprunner on Mac OS 1) Move the mouse pointer to an interface region that has an associated contextual menu (e.g. browser content region), and hold down the mouse button for 1-2 seconds. * RESULT - What happened Nothing. - What was expected A contextual menu should appear, as if the user had performed a Control-Click; we've been supporting this means of accessing contexual menus in every prior version (as does IE), and our users will be confused if it's suddenly missing. * REGRESSION - Occurs On Mac OS Apprunner (1999111112 build) - Doesn't Occur On Netscape Communicator 4.7 RTM [functionality not supported on other platforms] * CONFIGURATIONS TESTED - [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.6 - [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5. - [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

[Contextual menu issue; QA Assigning to self.]

reassigned QA contact to me & updated component. also gonna dup bug 21319 which was filed after this one (but i didn't know about till now :-).

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

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

taking popup/menu bugs. I hate my life.

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.

bulk accepting xpmenu/popup bugs. sigh.

Oh, not again ... *** This bug has been marked as a duplicate of 16766 ***

these aren't the same. one involves right clicking/dragging and this one involves click-and-hold behavior as implemented in 4.x for macOS.

Setting the keyword all open [4.xp] bugs to 4xp.

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

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

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

Not enough time to do this, reassigning to myself as p5 for m20, putting on HELP WANTED radar. If any Mac programmers care enough to do the work, we'd take a a patch if done by end of April.

reassigning to nobody

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

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.

I'm no Mac programmer, but I can take a look at this. Really, it shouldn't be much more difficult than firing off a timer, should it? Is there a setting I can grab using nsLookandFeel (or whatever it is) to determine how long the delay should be?

I have a _really_ rough implementation of this. Anyone want to take a look at it to see if I'm on the right track? By the way, what's the XP call to get the current pointer position?

Forget that second question. And I should note that right now my implementation isn't narrowed down to Mac, so anyone can take a look at it.

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

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

Could someone (probably pinkerton or sfraser) please answer Dean's questions? This bug is one of the ones most commented on in Macintouch's Netscape 6 forum <http://macintouch.com/netscape6.html>.

->pinkerton

You probably want to compare mouse cooridnates for mouse down and mouse up events, rather than trying to grab global coordinates in an XP way (I don't know if that's possible).

as indicated above, Jason Beach mentions this bug at http://www.macintouch.com/netscape6.html can we get a better milestone set on this bug?

M20 is going away. Bye Bye M20. Lets try for mozilla0.9

Scott Snyder (11/15/2000) mentions this bug/missing feature at http://www.macintouch.com/netscape6.html: Disaster: Holding the mouse button down does not create a pop up menu. This is my normal way of using Netscape and the most common command is "open in new window". Not having this is a huge time waster.

Did this get in the final release notes? Is it possible to update the online notes with something about this "missing feature"/bug? from Adam Aronson (11/15/2000) at http://www.macintouch.com/netscape6.html: Noticed one odd change that is very annoying to me, there are no longer any contextual menus for hypertext links! Prevoious versions of Netscape allowed you to hold down on a link, bringing up a contextual menu, that allowed you to do (among other things) open the link in a new window. This feature was very helpful w/ my dual monitor setup and a protracted surfing session. I want my contextual menus back!

Here's another comment but with an opposing viewpoint... from Terence Tan on 11/16/2000 comments at http://www.macintouch.com/netscape6.html: First, I don't think I'd like click-and-hold to bring up context menus. In my humble opinion, it's sooooo very wrong to have context menus that way. By Apple spec, the control-click (or right-click) is The Way to do it. No other application I know does click-and-hold anyway, except IE, and that's because they're making it easier for Netscape users. But, if you're concerned, see this. [link to: http://bugzilla.mozilla.org/show_bug.cgi?id=39622]

here is one more related comment from http://www.macintouch.com/netscape6.html (from Deborah A. Levinson on 11/16/2000): Must access contextual menus with ctrl-click instead of click-hold. They could have implemented both; it wouldn't have hurt them, and we Mac users wouldn't have to start thinking like Windows users.

Removing myself from the list of cc's. Didn't release note because in general we're not release noting stuff that we didn't do; just stuff that isn't working right.

changing severity to enhancement, since this currently works properly according to Mac HIG, and nobody has cited any specification or requirements documents that that called for long-click.

While the long-click method for is not part of Apple HIG, it was a feature introduced with Netscape, and latter propogated to all Mac browsers from IE to iCab and OmniWeb. Despite the fact that the HIG does not list the method, all Mac browser users have come to expect this way of interacting with their browser. I too would site the numerous posts in Mac newsgroups and message boards wondering why this "enhancement" is not present in the "final" version of Netscape 6 as copious evidence that it is something quite important to providing a usable browser for the Mac.

I just meant that this is an unimplemented feature, rather than a defect. Despite the hyperbole, I would be very surprised if as many as 10% of Mac users were even aware of context menus at all, given how undiscoverable they are. On Macintouch, only 5 people mentioned it, and one preferred the current behavior. Only 4 people mentioned it on MacFixIt. I didn't see any mention of this at all on c.i.w.b.mac. It would be good to implement it if we have time (I like it too!), but it still seems low priority.

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

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

i have this limping, but it is over-zealous. it pops up the context menu whenever you select text or use the scrollbar ;) i can check it in, it's all behind ifdef's if i can get some help from external people.

Shouldn't this be implemented in chrome? ie blocked by a hidden pref instead of ifdefs?

Mike, do you want to take a look at what I have and see if there's anything you can use?

Do we have any luck on getting this in rough for mozilla 0.8 and having it polished for 0.9?

So, judging from Mike's comments it would seem there are two exceptions left to implement. (1) If any object (such as text, or a proxy icon, or a scrollbar thumb, or a tree column) is being dragged, the context menu should not display. (2) If the mouse is moved 0.5em or more (where an em is measured with respect to CSS `menu' font, so 0.5em == 6px usually), either horizontally or vertically, in the first second after mousedown, the context menu should not display. As a niggly related detail: When the context menu does open, it should open with the top left corner of the first item (or the top left corner of the default item as in bug 37596) positioned 0.5em north and 0.5em west relative to where the cursor was on mousedown, *not* relative to where the cursor is when the menu is opened. (The horizontal position may be further to the west if there is not enough space on the screen to the east of the cursor.) This is the behavior on 4.x, and it's taken me a few minutes to work out why it's implemented this way -- it's to reduce the error rate for users who begin to move the mouse towards their desired context menu item just a wee bit too early. The menu still opens where they were expecting it to, so their muscle memory is preserved.

Mike, email me your code sometime, or check it in, or whatever. The idea that I had going a while back wasn't as over-zealous as yours sounds, so maybe I can piece the two together to make something spanky.

dean, i just posted my files (sorry they're not diffs, my tree died and i was lucky enough to save the files before i wiped it). let me know what you come up with. i'd like to see this happen.

So are the only problems the two that you described back on Dec 6? Also, what's the filename of the second attachment, just so I don't screw it up - nsXULElement.cpp?

the two files are nsXULPopupListener.cpp and nsXULElement.cpp. the problems that i remember seeing were that holding down the mouse to select text or to drag the scrollbar (or holding down the mouse in a scroll arrow) would bring up the context menu. i'm not sure why the dragGesture wasn't killing the timers. also, dragging items in trees wouldn't kill the timers so you'd get context menus. it could be real easy to fix...

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

nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)

Hey Mike, sorry I haven't had a chance to look at this yet. I moved recently and haven't gotten my high-speed link back up yet. And I ain't pulling the source down over a 33.6 link.

this will be much easier with mkaply's contextmenu event.

got a fix. hope to land tonight.

mostly landed, what remains: - scroll thumb still shows context menu - list boxes - html buttons

"scroll thumb still shows context menu" I'm pretty sure that's more than just what you're doing. I can right-click on a scroll thumb and get a context menu. I'm pretty sure there's a bug on this already, however I can't find it.

sure it's a bug that the scrollbar has context menus, but now we can't dismiss it as "silly user, don't right click on a scrollbar!" because they are just clicking and holding like normal.

Oh hey, you're right! Blake did some work on this before. Blake, did you ever get anywhere in eating the right-click on the scrollbar thumb?

in _theory_ we should be able to add an contextmenu event handler in xbl to the scrollbar (hyatt and i hooked that up yesterday) but alas, that doesn't seem to help. maybe i did it wrong.

Can we just use style to say what content is 'context-menuable'?

k, i have fixes for all of these. will try to land today.

I appreciate your new fix, but context menu should not be evoked when the cursor is on the scroll bar.

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

major issues dealt with. any problems should go into other bugs.

OK, I'm trying to verify this and, as I've proven before, I'm dumb. How do I set CLICKHOLD_SHOWS_CONTEXTMENU in Win32? I tried setting it =1 on the command-line, but I'm not getting any context menus.

Dean: you need to define that symbol at compile-time so that the appropriate listener code is compiled. Mike, would it make any sense at all to make this behavior pref-able so people on non-Mac platforms can get it if they want to? (hidden pref, of course)

Ahhh, Mike changed the file and define. The define is CLICK_HOLD_CONTEXT_MENUS and is used by content/src/events/nsEventStateManager.cpp. Maybe it's just Windows, but this is kinda shaky. No events get through to the context menu until I release the button, which means I lose any selected text and it takes an extra click to select the item. This is about what I had run into with my implementation. But hopefully this is just Windows. Works well for all elements on a page, including plain text, images, and form controls. 1. Should this work for the Back and Forward buttons on the toolbar? Currently it doesn't. 2. If you click-hold on the drop-down arrow on the back and forward buttons, you'll get one context menu immediately and then a duplicate menu after the timer fires. Not sure how to handle that one. Maybe LaunchPopup() should cancel any pending click-hold timers. 3. It's been a while since I've been on a Mac. Should I be able to click-drag to select text, stop moving the mouse but keep the button down, and have a context menu pop up?

bug 74380 covers the context menu on scrollbar issue

why do you want this on win32?

1) no 2) ben needs to turn of context menus for the toolbars 3) no

I don't see why we would support this anywhere but Mac OS.

Could be useful for PDAs/webpads which effectively have one "mouse" button.

then they can #define it in the ESM.