Closed Bug 18726 Opened 25 years ago Closed 23 years ago

[feature] Long-click means of invoking contextual menus not supported

Categories

(Core :: XUL, enhancement, P5)

Product:
Core
Component:
XUL
Platform:
PowerPC
Mac System 8.5
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9

People

(Reporter: elig, Assigned: mikepinkerton)

References

Details

(Keywords: helpwanted)

Attachments

(2 files)

popup listener with click-hold listeners in it.
33.61 KB, text/plain
Details
xul element with added listeners
142.06 KB, text/plain
Details 
* 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).
QA Contact: claudius → elig
Summary: [4.xP] Long-click means of invoking contextual menus not supported → [4.xP] Long-click means of invoking contextual menus not supported
[Contextual menu issue; QA Assigning to self.]
Status: NEW → ASSIGNED
Target Milestone: M16
Component: XP Toolkit/Widgets → XPMenus
QA Contact: elig → sairuh
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. ***
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
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.
Component: XPMenus → XP Toolkit/Widgets: Menus
bulk accepting xpmenu/popup bugs. sigh.
Status: NEW → ASSIGNED
Oh, not again ...

*** This bug has been marked as a duplicate of 16766 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → ASSIGNED
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
Summary: [4.xP] Long-click means of invoking contextual menus not supported → Long-click means of invoking contextual menus not supported
*** 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. ***
Summary: Long-click means of invoking contextual menus not supported → [feature] Long-click means of invoking contextual menus not supported
Whiteboard: 3 days?
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.
Assignee: pinkerton → trudelle
Status: ASSIGNED → NEW
Keywords: helpwanted
Priority: P3 → P5
Target Milestone: M16 → M20
reassigning to nobody
Assignee: trudelle → 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.
QA Contact: sairuh → jrgm
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
Assignee: nobody → 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?
Keywords: nsmac2
M20 is going away. Bye Bye M20. Lets try for mozilla0.9
Keywords: mozilla0.9
Target Milestone: M20 → 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!
Keywords: relnoteRTM
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]
Depends on: 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.
Severity: normal → enhancement
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.
Status: NEW → ASSIGNED
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?
Keywords: mozilla0.8
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.
No longer depends on: 39622
Target Milestone: mozilla0.9 → mozilla1.0
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. ***
Keywords: mozilla0.8.1
Keywords: mozilla0.8
nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release)
Keywords: nsdogfood
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.
Keywords: nsCatFood
Keywords: nsdogfood
this will be much easier with mkaply's contextmenu event.
Depends on: 36665
Target Milestone: mozilla1.0 → mozilla0.9
got a fix. hope to land tonight.
Whiteboard: 3 days? → fix in hand
mostly landed, what remains:
- scroll thumb still shows context menu
- list boxes
- html buttons
Whiteboard: fix in hand
"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. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → FIXED
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.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: