Closed Bug 49844 Opened 24 years ago Closed 23 years ago

Add option to make context menus display on button down

Categories

(Core :: XUL, enhancement, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
enhancement

Tracking

()

Status:
VERIFIED DUPLICATE of bug 89308
Milestone:
Future

People

(Reporter: deanis74, Unassigned)

References

Details

Attachments

(1 file)

Context menus on mouse down in windows
7.70 KB, patch
Details | Diff | Splinter Review 
This is new, and the behavior that I'm assuming we definitely don't want.  Until
today (or really recently) context menus displayed on right-button down.  Now
all of a sudden they're not displaying until right-button up.  Did this slip in
there somewhere?

Build 2000082204 on WinNT
This was fixed with the fix for bug 48838, and it was intentional.  Standard 
Windows behavior is that the context menus appear on mouseup, whereas standard 
Unix behavior is on mousedown...so it was ifdef'd accordingly.  I think this is 
a WONTFIX unless non-win32 platforms aren't behaving correctly?
(Damn, blake's fast ...) . One major exception to the party line is Nav4.x
on win32, which brings up a context menu on mousedown, which allows for the 
convenient 'mousedown-sweep-mouseup-to-select' behaviour.
This is a bad move. People really miss how 4.x's context menus behave. Read
through some of the comments for bug 16766, and its 16 duplicates, and you'll
see that this is one of the things that people really miss in the current
context menu implementation. Count me as one of those people.

We've now moved to mimic the behavior of IE's context menus, not displaying
until mouse up, and this is behavior that I despise. It's one of the larger
contributers to my not using IE.

I'm having trouble seeing how this had to be changed in order to fix bug 48838.
I agree.  It's much easier to use the context menu if it appears on mousedown, 
and even moreso once bug 16766 is fixed.  And it's important for backwards 
compatibility.

Reassigning to me so I can fix once we reach a decision on this.

(Nope, it wasn't needed to fix bug 48838, but I know it was in that patch 
anyways for whatever reason.)
Assignee: pinkerton → BlakeR1234
Keywords: 4xp
Adding Hyatt and Pinkerton to the CC list

No, it wasn't needed for the other bug fix, it was done for platform compliance.
Be careful before you run off and revert the behavior... it fixes other bugs
if you use IE, the win32 desktop, or any other msft app, the context menu appears 
on mouse up.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
There are many places in the product when we've shunned tradition for added 
usability.  The question here is whether it's easier to obey platform standards 
(and leave it the way it is) for added usability and speed (it's much quicker 
to mousedown, scroll down to the item you want, and mouseup to trigger the 
action than it is to mousedown, mouseup, scroll down to the item you want, 
mousedown, and mouseup again).  Still, I don't care all that much either way.  
cc'ing Matthew for comment
Don't forget right-click dragging, which you couldn't do if the context menu 
came up on a mouse down.

We are following the platform here.  I think this is the right thing to do.

hmm, good point.  I've lobbied for platform consistency nearly everywhere else 
in the product that allowed for it, and I'm starting to think we should mimic 
platform behavior here as well.  Our current behavior just conforms to platform 
standards -- whether or not it's the best choice for users really isn't the 
concern of our app, it's a design flaw in the OS itself.
Status: RESOLVED → VERIFIED
I almost always agree with platform standards, too.  And I know where this non-
standard behavior comes from.  It's a carry-over from the latter days of 
windows 3.1, when there wasn't a standard behavior because context menus were a 
new concept.

I like the right-click and drag, so I'm torn on where I stand on this on.

Bug 16766 should be marked as WONTFIX, as well, given the resolution of this 
bug.  And that's going to make more than a few people unhappy.

So someone volunteer to make it a preference. I don't always agree with the
"everything must be configurable" linux-esq approach, but this could be made a
pref without much fuss.
You mentioned, though, that this fixes other bugs.  Which ones would we have to 
keep in mind?
The mouse down wasn't focusing like it should.  This was fixed on Linux and Mac 
though, so it would work on Win32 as well now.
So then you think that having context menus work on either mouse up or mouse 
down would make no difference to the rest of the app?

If we make this a pref, we'll have to re-open 16766, though.
no pref! no pref! i'll have to mark those new bugs with the pref on won't fix.
Blocks: 16766
Mike - why?  Future bugs that need the mouse-up behavior?
Oh, ouch. If `Back' in the context menu requires two clicks (as it does if you 
only bring up the context menu on mouseup), then with a typically-sized browser 
window, going to the Back button is quicker -- and you might as well not have 
`Back' and `Forward' in the context menu at all.

Where in Mozilla do we ever, or will we ever, use right-click dragging? Given 
that we'd have to come up with an equivalent action on Mac, I don't think we 
will.

And anyway, I can pull out my `consistency of the closest aspects' rule and say 
that it's more important for context menus to behave the same way as ordinary 
menus (opening on mousedown) in the same app, than it is for them to behave the 
same as context menus on other apps.

That menu pulldowns trigger on mousedown and context menus on mouseclick is an 
unfortunate design flaw of Windows, but not our concern.  When Windows fixes 
the design flaws in their stnadards, we will fix our app to conform to them.  
For now, we are doing the right thing by following OS standards.
*** Bug 50771 has been marked as a duplicate of this bug. ***
If you make the context menu appear on mouse button up you can't use them if you
use focus-follows-pointer on NT - the menu disappears once the pointer enters
the menu. Given that every other menu type appears on button down, it seems
inconsistent to have just context menus on button up. 
This looks to be a bug in the interaction of our menus and the x-mouse behavior.  
Because x-mouse behavior works fine with native context menus.  Toby, can you 
file a separate bug on that?  I duped bug 50771 because it was related to the 
mousedown/mouseup issue.  In the new bug, just mention the x-mouse problem.
Thanks!
I've filled in a bug report for the interaction between x-mouse and context
menus on NT in bug #50798
This is basically a debate between two standards, the Windows standard, and the 
4.x standard. I'm going to wish for convenience (4.x) over normal (Windows) 
behavior. Is there anyone who is chanting for Windows mouseup behavior actually 
doing so because they like it (rather than just "compliance")?
Whiteboard: Being discussed in n.p.m.ui
*** Bug 52169 has been marked as a duplicate of this bug. ***
*** Bug 56378 has been marked as a duplicate of this bug. ***
(story time)
I downloaded M18, I liked it, I loved it, I right clicked, I though, "wtf? is 
Mozilla lagging?" I right clicked some more, I realized it wasn't lagging, but 
it was actually appearing on mouseup, I said, "eww.. this is poo" I closed 
mozilla and promptly posted that "bug" (using NS 4.75)  One of the major reasons 
I don't use IE is because of that, if you make mozilla like that too, I'll be 
stuck with NS 4.75 for many years...

I'm interested in where this is marked as the standard.  I looked in the msdn, 
and didn't find it.  I played around with a lot of apps, and it seems 50/50.  If 
you start arguing that it must behave like one of microsoft's context menus, you 
should add that lame fading in on 2k/me and the menu pop up sound.

Why even bother making your own browser if you make it exactly like IE?
Microsoft sure as hell won't listen to the people and change their messed up 
ways, that's what you're here for.
> I played around with a lot of apps, and it seems 50/50.

Could you name some of those apps?  Might be interesting.
some apps that do on mousedown: netscape 4, mirc, secure crt, word perfect.
even though it's only 4 programs, they are 4 programs I use a lot.

While many programs do use the mouse up menu, they do so for a purpose (like on 
the desktop, you can select icons with the right button).  There is really no 
reason for mozilla to wait.

I think one reason I noticed it on mozilla, and didn't on some of the other 
programs is the menu is noticably slower in mozilla than in (for example) 
notepad.  I can actually move my mouse across the screen in the time it takes 
the mz menu to come up.  Considering I use the menu for (primarily) navigation, 
that delay is very apparent, and very annoying.  If it came up on mouse down, 
the delay shouldn't be noticable.
Perhaps another reason is the popup menu is used quite heavily in mozilla 
compared to other programs.  Most programs use them for doing things like 
cutting or pasting, which most people do with the keyboard anyway (assuming it's 
text).  Navigation is a mouse function.  There are keyboard shortcuts, but 
normally your hand is on the mouse anyway for link clicking.  If the only thing 
people wanted to do with the menu is copy text, there probably would be no 
debate right now.  The "flick of the wrist navigation" is a *very* important 
feature; it's the difference between a usable browser and a waste of bits imho.

It seems silly there is even an argument.  People won't care if it's on down, 
but people WILL care if it's on up.   The choice seems obvious to me.
URL: n/a
Whiteboard: Being discussed in n.p.m.ui
[For help in future counting: 5 dups of this bug were marked as dups of bug 
16766, so this bug has 8 dups so far.]

I'm with Brian and Matthew here.  As stated by Matthew, it's highly unlikely
that right-click dragging will be used in Mozilla, so the "menu on mouse-up"
approach seems to have zero benefits other than being the Windows standard.

And I really cannot see why a user would get annoyed if the menu pops up on
mouse-down instead of mouse-up.  The other way around, though, it's really
frustrating for those (apparently numerous) users who like using the context
menu.

I think this should be reopened.
Right dragging should be enabled for mozilla.  There is a bug by Hixie for 
support of right dragging links to the desktop to get an active desktop option. 
This would require right drag capabilty because even w/ modifier keys active 
desktop is probably not one of the possible simple drag events.
Given the choice between being able to go Back with {mousedown, drag ~3 pixels, 
mouseup} (something I'd do several dozen times a day), and being able to
right-click-drag an item to the desktop to make it my Active Desktop (something 
I'd do about once every two or three years) ... I know which one I'd choose.

odd, i'd just click the back button.  [If my mouse was near it] Actually, i'd 
press alt-left, but...

As for not violating the OS. I just gave an example, i can find better ones if 
necessary, but that seemed to be sufficient evidence that we shouldn't violate 
os best practices.
recall that doing things this way fix _many_ serious focus-related bugs. You can
have those back if you like.
which ones did this one fix?  Earlier in this bug, Blake Ross said, "it wasn't 
needed to fix bug 48838, but I know it was in that patch 
anyways for whatever reason."  That's the only place I see another bug 
mentioned.  (besides the numerous duplicates mentioned).
Various other applications I use display the context menus on button-down
instead of button-up -- UltraEdit being the one I use most.  This is an absolute
showstopper bug for me; Mozilla/Netscape v.6 will remain nothing but a curiosity
for me until the context menu behaviour is changed back to match Netscape v.4.

I'm starting to think that this should really be made a preference - if those
focus issues that pinkerton brought up can be dealt with, that is.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
> I'm starting to think that this should really be made a preference

Another case of Yet Another Pref Syndrome ... Take two aspirins and see if you 
feel any better.

Ok, I'm reopening this. Nobody commenting in this bug *likes* the current 
behavior; it slows down back/forward navigation horribly; and the reasons given 
for retaining it are decidedly dodgy.

First, the `consistency with the OS' argument is negated by the fact that several 
popular apps (including 4.x) have been cited as opening the context menu on 
mousedown, and by the fact that Windows is inconsistent with itself since every 
other menu type does open on mousedown.

Second, the `allow right-click draggin' argument is nebulous, since no-one has 
been able to give any good examples of where this would be useful (see also bug 
25742, which has a similar lack of examples), and since it wouldn't work XP.

And third, no-one has cited any specific bugs to support the `it would expose 
other bugs' argument, apart from one bug which Hyatt said was already fixed. In 
any case, hiding bugs is not an excuse for making the user experience permanently 
worse.

Matt: I agree with you, except your complaint about too many prefs.  If we can
ever decide on how to implement a "very advanced" prefs page, this could go on
there.

Hyatt: I changed my build so that context menus displayed on button down, and
the focus problem is back.  How was it fixed on Mac and Linux?

All: If we want to do this, we're still going to have to fix bug 16766, which
was at one time xp before it was narrowed down to only Linux.  Also, popup menus
seem pretty slow these days, so we'll have to look into that.  Actually, we
should look into that anyway.
Hyatt: Found it - FireFocusOnTargetContent().

So that just leaves bug 16766, or maybe we should open a new one for Windows.
now that bug 16766 has been fixed, does that mean we can fix this one too?
Brian, sorry buy no.  The fix in 16766 is for Linux only.  That part of the code 
is a completely different world than Windows.
So then has a new bug been filed for windows?
Or should bug 16766 be reopened with "windows" added?
I don't know what I was thinking back in January with my comment about opening a 
new bug for Windows.  This _is_ the bug for Windows.
Blocks: 62040
Wow, this bug is on my list.  How did that happen? :-)

I can fix this, but I'm not intimately aware of all the bugs that hyatt and 
pink say will return from the dead if I do (if they'd like to explain them to 
me, I'll do it).  So passing back...
Assignee: blakeross → pinkerton
Status: REOPENED → NEW
according to msft documentation, context menus appear on mouseUp. Since we are 
now using the native WM_CONTEXTMENU event, that's what we get.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WONTFIX
However, as has been pointed out before, even Microsoft doesn't follow this 
'rule' -- applications in general seem to be split about 50/50 as to whether 
context menus appear on button-down or button-up.  The more useful behaviour is 
button-down, as you can button-down, highlight a context menu item, and select 
it with button-up, all in one smooth motion.  This is more user-friendly than 
the alternate behaviour, which requires two separate mouse events.

IE does context menus on button-up.  Imitating IE behaviours is not high on my 
list of priorities :).  It's one of the things I find most annoying in the UI of 
applications.

pinkerton: are you sure about the WM_CONTEXTMENU thing?  The reason I ask is 
because nsIContextMenuListener::OnShowContextMenu fires on mouse down.
vrfy.
Status: RESOLVED → VERIFIED
in the newest builds nsIContextMenuListener::OnShowContextMenu fires on mouse 
up.  perhaps you guys misunderstood me, I wasn't complaining that it should fire 
on mouse up.  I like it firing on mouse down.  that's the way god intended it to 
be.
Can we remove the wontfix status?  It makes me the shudder...
Brian: please don't mention god.  context menus should appear on mouseup on 
windows that's the spec and anything else you see is a bug.
I'm sorry, but in every single other case, the rule has been to adhere to the
current NS4.x behavior, and changes from this behavior must be justified.  This
context menu on mouseup thing is a big pain in the butt for the many people, and
big turnoff from mozilla.  Context menus on mouseup gets the user nothing, while
context menus on mousedown offer a faster way to browse and perform actions.

OS uniformity in a non-uniform OS is not a good justification for this.  If you
are so concerned about acting like other apps, there are bigger fish to fry,
such as using native widgets and hardwiring in the classic theme.  
there are features of using mouseup, there are reasons we don't use mousedown 
and these were discussed in other bugs. please take your complaints to a 
newsgroup.
we are using the win32 WM_CONTEXTMENU event. Period. Done. This conversation is 
over.

Please fix this.  This annoying problem is one of the few things that's 
preventing me from switching over to Mozilla from Communicator.  Also, just to 
add to what's above, this problem occurs on Win9x and Windows 2000 machines as 
well as on NT.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Unauthorized Reopen.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
.
Status: RESOLVED → VERIFIED
That's a bit harsh. This bug should probably be arranged thus.

Gerv
Severity: normal → enhancement
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Summary: context menus display on button up instead of down → Make context menus display on button down instead of up
Target Milestone: --- → Future
Reassigning to our friend, nobody.

Gerv
Assignee: pinkerton → nobody
Status: REOPENED → NEW
QA Contact: jrgm → nobody
we are _not_, i repeat _not_ going to fix this. We are following the win32 
guidelines and using WM_CONTEXTMENU. As a result, we are at the mercy of the OS 
to tell us when a context menu appears.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Mike, I'm not asking you to fix this. There are several good reasons for this 
bug remaining open:

1) It will show up on the mostfreq table and stop people filing dupes. This is a 
_very_ good reason. People whine about this all the time in newsgroups.

2) Someone somewhere may want to rejig things enough that this works for them, 
and make a patch available to anyone who wants it. It doesn't mean we have to 
accept it. Or do it as a pref.

If it's assigned to nobody, why do you care? You've already made it very clear 
indeed that a patch will not be accepted into the tree.

Gerv
No, Gerv, people do not whine all the time on newsgroups about this bug not 
appearing on the mostfreq table. They whine all the time on newsgroups about 
this bug not being fixed. There is a difference.
Shouldn't this be closed as WONTFIX, not FIXED?
*** Bug 85530 has been marked as a duplicate of this bug. ***
Wow.  My bug (bug 85530) is but one of many duplicates citing user grief about
context menu behavior in Mozilla.  (I thought I had done a better search for
duplicates before writing bug 85530; but apparently not!)

If you see my commends on that bug, however, you will see that I am definitely
of the opinion that Mozilla should take either of the following approaches:

1) Violate Windows 'standards' on context menu behavior and respond to
right-mouse-down.

2) Provide an 'Advanced UI' preferences category allowing the user to decide. 
And the default could be 'On right-mouse-click,' as long as I can choose otherwise.

I am, on one hand, happy to see that I am not the only one who considers
Mozilla's context menu behavior to be an egregious step away from Netscape and
toward IE.  Prior to reading everyone's comments, I thought I was a lone
Netscape 4.x user who despised IE for some very simple UI reasons (context menu
doesn't appear until mouse-up; 'open in new window' allows OS to size window
rather than inheriting current window size).

I agree with everyone who has written a statement of the flavor: 'I am sad that
I will have to make the decision between a buggy and no longer supported
Netscape 4.x, with its extremely quick mouse-based navigation -or- a solid,
evolving Mozilla with UI quirks that remind me of why I don't use IE.'  I
absolutely love the latest Mozilla build (the first I've used since an early
Alpha) and the fact that users can respond and provide input on issues like
these is proof that this model of development is more user-friendly.  I feel,
decidedly, that Mozilla's developers must recognize the enormous clamor around
this issue and provide at least the option of choosing the context menu's behavior.

I really enjoyed the comments of another Brian: 'Why even bother making your own
browser if you make it exactly like IE?'  Netscape 4.x users have been staving
off the IE steamroller for a long time and I believe they expect Mozilla to be
their next browser platform.
Even though I commented differently a while back, I'm fine with the behavior 
now.  It's standard Windows behavior.  It doesn't inconvenience me at all.  If 
this is enough to make someone think that we're making a browser that's 
"exactly like IE", then they're not looking very deep below the surface.  Just 
wait till we build the Active Desktop support.  ;)

And even if we were to enable the context menu on button-down, it doesn't work.  
The menu doesn't grab capture until the mouse button is released (early bug 
16766).
This is still a large problem for me -- the user interface in this state slows 
me down significantly compared to context-menu-on-button-down behaviour of 
Netscape 4.x.
The function that I use this menu for 99% of the time in 4.x is Open in New 
Window.  Now that I can do this with a single-click of the middle mouse button, 
I don't use the menu at all.  I know, many mice don't have a middle button.
I know this has been decided to keep the OS behavior of menu on release, but 
just for the sake of matching the OS?  It goes against usability.  You'd think 
the reasons for context on mousedown outwiegh the resons for on mouseup.  People 
using Netscape didn't have a problem with the menu on down method.  It's faster 
and not as awkward to use.  This is one of the things about IE I don't like.  
Coudn't there be a setting in preferences somewhere to have context menus on 
down?

I hate it when I use Mozilla and it starts to feel like IE.
Please, people, stop referring to the current behavior as the `OS standard'.
When there are many, many Windows apps which open the context menu on mousedown,
including apps in Microsoft Office 2000, and even some parts of Windows 2000
itself, referring to opening on mouseup as a `standard' is misleading at best
and disingenuous at worst.

And no, there is no point in making this a preference, since no-one prefers the
current behavior over the 4.x behavior. (No-one who's spoken up in this bug,
anyway.) Either they tolerate it, or (like Dean) they use a middle mouse button
instead, or (like brian, Brian, and Charles) they go back to 4.x.
<i>And no, there is no point in making this a preference, since no-one prefers
the current behavior over the 4.x behavior. (No-one who's spoken up in this
bug, anyway.)</i>

Are you kidding?  Plenty of people have spocken up here and in the newsgroups.  
From this bug alone:

Dean Tessman
------------
<i>The function that I use this menu for 99% of the time in 4.x is Open in New 
Window.  Now that I can do this with a single-click of the middle mouse button, 
I don't use the menu at all.  I know, many mice don't have a middle button.</i>

Brian Hauer
-----------
<i>If you see my commends on that bug, however, you will see that I am 
definitely
of the opinion that Mozilla should take either of the following approaches:

1) Violate Windows 'standards' on context menu behavior and respond to
right-mouse-down.

2) Provide an 'Advanced UI' preferences category allowing the user to decide. 
And the default could be 'On right-mouse-click,' as long as I can choose 
otherwise.</i>

anon0322@yahoo.com
------------------
<i>Please fix this.  This annoying problem is one of the few things that's 
preventing me from switching over to Mozilla from Communicator.  Also, just to 
add to what's above, this problem occurs on Win9x and Windows 2000 machines as 
well as on NT.</i>

Ben Ruppel
----------
<i>I'm sorry, but in every single other case, the rule has been to adhere to the
current NS4.x behavior, and changes from this behavior must be justified.  This
context menu on mouseup thing is a big pain in the butt for the many people, and
big turnoff from mozilla.  Context menus on mouseup gets the user nothing, while
context menus on mousedown offer a faster way to browse and perform actions.</i>

That's just the first four I saw and won't list them all for obvious reasons.

A lot of people want this.  Why not just provide an undocumented pref?
Oops, I read it wrong.  You said no one prefers the current behaviour...
As I alluded to earlier it's not as easy as just changing it from button up to 
button down.  When the context menu was displaying on button down, it didn't 
work.  You still had to release the mouse button in order for the menu to start 
responding.  A lot of time was spent trying to diagnose it, but no resolution 
was found.  It's not an excuse, but I just wanted to make sure that people 
realize it's a deeper issue than it appears.
actually it is that easy.  I run my own special build of mozilla where the menu
comes up on mouse down, and I have not seen any bugs because of it.  fyi, the
code I change is in nsWindow.cpp
/*
        case WM_CONTEXTMENU:
            result = DispatchMouseEvent(NS_CONTEXTMENU);
            break;
*/
        case WM_RBUTTONDOWN:
            {
... some code snipped for brevity ...
            result = DispatchMouseEvent(NS_MOUSE_RIGHT_BUTTON_DOWN);
            result = DispatchMouseEvent(NS_CONTEXTMENU);
            } break;

sure it's not very pretty, but it works perfectly (for me at least).
Using this code I still run into the same problems that I mentioned before. 
Although the context menu shows up on right button down, it doesn't respond 
(items don't highlight) until I release the mouse button. Then I have to click 
again to select an item from the menu.

Also, you can't take WM_CONTEXTMENU out completely or you'll toast keyboard 
support for context menus (VK_APPS).  Here's some modified code, using a define 
set in makefile.win.

        case WM_CONTEXTMENU:
        {
            // if the context menu is brought up from the keyboard, |lParam|
            // will be maxlong. Send a different event msg instead.
            PRUint32 msg = (lParam == 0xFFFFFFFF) ? NS_CONTEXTMENU_KEY : 
NS_CONTEXTMENU;
#ifdef WIN32CONTEXTMENUONMOUSEUP
            // context menu from the mouse is handled in WM_RBUTTONUP - only
            // send the context menu if initiated from the keyboard
            if (msg == NS_CONTEXTMENU_KEY)
#endif
            result = DispatchMouseEvent(msg);
        }
            break;

          ......

          case WM_RBUTTONDOWN:
          {
            ......
            result = DispatchMouseEvent(NS_MOUSE_RIGHT_BUTTON_DOWN);
#ifdef WIN32CONTEXTMENUONMOUSEUP
            result = DispatchMouseEvent(NS_CONTEXTMENU);
#endif

well I'll be damned, you're right *opens mouth, inserts foot*
I never noticed that one because I use real popup menus (ie: TrackPopupMenu()). 
 I can assure you it has never crashed because of it though :)
Actually. What in the world. Pinkerton and I have both commented that the way 
it is, is the way it should be. Do we not exist?

<q class="useless-repetition">
I prefer the current implementation. I didn't speak up because I didn't feel a 
need to spam people over a bug that has been fixed for a while.</q>

mpt: please don't make sweeping generalizations about products w/o including 
steps to reproduce.
> Pinkerton and I have both commented that the way it is, is the way it should
> be.

Um, no. Pinkerton said that it's the way that it is not because he preferred it
that way, but because:
*   It's what WM_CONTEXTMENU does -- which is true, but so what? We've worked
    around bugs in the Windows APIs before. (Just ask danm.)
*   It apparently fixes other bugs -- but he has failed to name any of them,
    despite repeated requests to do so.

You said it should be the way it is because:
*   You think Mozilla should support right-click-drag, an action which the User
    Interface Hall of Shame has described as [emphasis in original] `perhaps the 
    *least* intuitive operation ever conceived in interface design'.

> mpt: please don't make sweeping generalizations about products w/o including
> steps to reproduce.

-sigh- ... Fine, then. Here's steps to reproduce:
*   Mousedown with the right mouse button.
What you should see:
*   A context menu appears.
What you actually see:
*   The context menu does not appear until the mouse button is released.
*   You need to click twice, instead of once, to use the context menu.
*   It's unnecessarily difficult to get rid of the context menu once you've
    opened it.

Problem occurs with:
*   Mozilla build 2001061520, Windows 98

Problem does not occur with:
*   Adobe Acrobat Reader 4.0
*   Adobe Illustrator 9.0
*   Adobe ImageReady 3.0
*   Corel Quatto Pro 8.0
*   Corel WEB.SiteBuilder 8.0
*   IDM UltraEdit 8.0
*   Microsoft Photo Editor 3.0
*   Microsoft Excel 2000
*   Microsoft Publisher 98
*   Microsoft Publisher 2000
*   Microsoft Word 97 (toolbar area only)
*   Microsoft Word 2000 (ditto)
*   Microsoft Windows 2000 Disk Defragmenter
*   Microsoft Windows 2000 IME Pad
*   mIRC
*   Netscape Communicator 4.x
*   RealPlayer 7.0

Problem also does not occur with:

- UltraEdit v.7.10a
- F-Secure SSH v.1.1

"Context-menu-on-right-button-up" is definitely _not_ a Windows standard, 
despite what lies the documentation may contain.

Ok, i have bery few of those programs, the behavior mpt suggests sdoes not 
appear to occur in the w2k as disk defragmenter, he'll have to provide better 
teps tp reproduce.


it does kind of occur in acrobat5 (a dn corel quatropro 8, but both of them 
were not very happy when i ran them.

mpt also listed mirc which is a program which should earn a ui hall of shame 
slot, but that's ok.
WE ARE NOT CHANGING THIS IN MOZILLA.  GET OVER IT.

Well, if that is your attitude, it is a big f@#@in' CRYING SHAME that you've had
a chance to start over fresh, and chose to break your darn browser.  Have fun
with crapzilla!
> WE ARE NOT CHANGING THIS IN MOZILLA.  GET OVER IT.

Heh, that's funny.  I thought Mozilla was an effort to build a browser and 
listen to users input on what they liked and disliked.  Where everyone 
contributes somthing and they're a part of the project.  I guess the programmers 
only listen to other programmers.

There's been enough people that don't like this IE style "feature", and it could 
probably be made to do both if people weren't lazy.  But what good is the drag 
functionality good for?  How much drag and drop do you really _need_ in a 
browser?

It's pretty sad when the developers are "screeming" at people for making 
suggestions.
I'm sorry, I usually have a lot of respect for the mozilla programmers and their
decisions, but the responses I've seen in this bug are utter baloney.  It seems
that we used to have context on buttondown working just fine, but then a bunch
of other bugs popped up.  Rather than fixing the bugs, it was decided to go with
the quick fix by changing mozilla behavior.  Mozilla usability was compromised
for the sake of a quick hack, and non-existant "OS standards" are being used as
a crummy crutch in arguments.
Context menus on right-button down NEVER worked properly.  See bug 16766, which 
originally was for all platforms and also my comments from yesterday.

Oh, and here's a tip.  Don't call people lazy, especially when they, speaking 
personally, put in countless hours trying to work on 16766.
We match the OS behavior here.  We respond to the native message which also 
gives us shift+f10 for key access to the menu (and should the key change in the 
future, we'll continue to support the correct OS key).  Changing to respond to 
this message is not a "hack".  The code is simpler and more elegant, and we're 
matching the correct Windows behavior (and we're doing it ONLY on Win32).  
 
This is the whole point (which is apparently being missed by some developers):  
this isn't "correct Windows behaviour".  Even MS-Office 2000 doesn't behave this 
way.

It seems that roughly 10% of the userbase that has commented on this issue (in 
this bug and the various duplicates) likes the current behaviour, and about 90% 
feel very strongly that the previous behaviour made for a significantly better 
user experience.

You are wrong.  Here's a sampling of apps.  I'll use UP and DOWN in the list 
below to indicate menus that come up on a mouse up and a mouse down 
respectively.

Visual C++ - UP
Internet Explorer - UP
Outlook Express - UP
Notepad - UP
Wordpad - UP
Adobe Photoshop 5.5 - UP
Office (Word 97) - UP

... and so on ...

I'm not sure what OS you're running, pal, but every app I've tried (including 
Office) is bringing up context menus on a mouse up.

In fact, the only app (on my machine) that I can find that deviates from this 
behavior is Netscape 4.7.

Also, we've made it clear that this is the OS behavior.  We are responding to 
the Win32 generated WM_CONTEXTMENU message.  The OS itself is generating that 
message on a right mouse up and on SHIFT+F10.  We are not listening to the 
mouse or the keyboard, and are instead letting the OS decide when a context 
menu should be invoked.

So when we say OS behavior, we literally mean that Win32 is deciding when to 
send us that message, and its default behavior is to do this on a mouse up 
(hence the reason nearly every app on Win32 has mouse up behavior, since you 
have to deliberately deviate from the OS behavior to make it come up on a mouse 
down).

> > It seems that roughly 10% of the userbase that has commented on this issue 
> > (in this bug and the various duplicates) likes the current behaviour, and 
> > about 90% feel very strongly that the previous behaviour made for a 
> > significantly better user experience.

> This bug has 18 cc's, and 10 votes. We don't consider bugs w/ 100 cc's or 
> votes as representing even 1% of our userbase. Please refrain from making 
> extremely in accurate comments.

That's why I said "...of the userbase which has commented on this issue (in this 
bug and the various duplicates)...".

It's a bug.  It's a nasty one.  Lots of users submit this bug.  Some of the 
developers seem to feel that this is not a bug because somewhere the Windows 
docs say this is "standard OS behaviour".  Never mind that Mozilla doesn't act 
this way on any other platform.  Never mind that most of the applications I use 
on win32 don't behave this way.

The reason so many applications do not follow this "standard" Windows behaviour 
(including Office 2000) is that the standard is broken, and less usable than the 
obvious context-menu-on-button-down.


David Hyatt wrote:

> You are wrong.  Here's a sampling of apps.  I'll use UP and DOWN in the
> list below to indicate menus that come up on a mouse up and a mouse down
> respectively.

[...]
Office (Word 97) - UP


No (I mean 'NO!' ;-), as somebody mentioned above:

*   Microsoft Word 97 _(toolbar area only)_
*   Microsoft Word 2000 (ditto)

Right-klick in the *toolbar* of MS Word 2000 - and voilà, the menu appears on
mouse-down.

Please, please solve this bug, _make it an option_ how the context menu comes up
- or it will never be quiet around this bug again...
Do see Matthew Thomas' (mpt's) list of applications that use a right-mouse-down
as an invocation of the context menu. He labels his list, "Problem does not
occur with..."

I think this whole discussion is getting side-tracked, though, into a discussion
concerning which apps behave one way or another. And sadly, it may have become
way more heated than it needs to be. Nevertheless, many people have noted that
the majority of users who have spoken up about this so far would prefer a
right-mouse-down context menu.

The bugs that are introduced by doing this change notwithstanding, can't this
issue be at least marked as something the developers will look into more in the
future? I can understand tabling it for the time being due to attending to more
important matters, but eventually, it should be addressed. Obviously it's not
impossible to support a context menu on right-mouse-down--Netscape 4 has been
doing this for years.
So Office is internally inconsistent, choosing to (within the same window) 
sometimes invoking a context menu on a mouse up and other times on a mouse 
down.  Gee, that's a great user experience.

Also, mpt's list is not correct.  For example, I tested RealPlayer, and the
context menu comes up on a mouse up even though it's on his list as coming up on
a mousedown.

It is quite clear to me that the vast majority of Win32 apps have context menus
that are invoked on a mouse up.  I've looked at 40 apps now on my machine, and
they all bring up the context menu on a mouse up except for Word in the toolbar
and Netscape 4.7.  

So I'm sorry, but the assertion that this is not the OS behavior is bogus. 
Maybe some very popular apps make the decision to use a mouse down, but they are
quite clearly a minority.
Let's go to Redmond and hack the damn "OS behavior" for our own good.
I think I heard hyatt say that if people generate more spam on this bug, he'd be 
interested in fixing it.  Go for it, guys!
what if redmond, in Windows 2002 decides to change wm_contextmenu from mouse up 
to mouse down (or even makes it an option), will the code be able to handle it? 
 if not, then that really is a bug that should be fixed.  the code shouldn't 
assume it's being called by right mouse down-up unless it's actually doing if 
(mouse up){ }.

btw, this really should be marked "WONTFIX" (if you admit it's a bug but don't 
feel like fixing it) or "INVALID" (if you refuse to admit it's really a bug).
That's the whole point of listening to the message.  If Windows does change the
behavior, yes, we'll pick it up automatically.

In an attempt to say something new in this discussion: Even Netscape 4.x behaves
differently in different areas. If you right-click in the adress bar, the menu
comes up on *mouse-up*. If you rigth-click on a link or something like that, it
comes up on *mouse-down*, as desired by quite a few users and programmers here.
I wouldn't say this is inconsistently, I think it is fully intentional. It makes
sense because you are faster in such often-used actions like opening a link in a
new window or view source or copy link to clipboard, although the standard menu
comes up at mouse-up. On the other hand, I would say the different behaviour of
MS Word (text: mouse-up - toolbar: mouse-down) is inconsistent, I seems not to
foollow any careful consideration.

So, please solve this bug, so that you are able to use Mozilla like Netscape
4.x, at least as an *option*.
yes, the code will open the menu on mouse down, but will you be able to *use* 
the menu?  from what I can tell, the menu will appear, but you'll have to 
release the button, then click again to select any item.  sounds like a bug that 
needs fixing to me.
*** Bug 83764 has been marked as a duplicate of this bug. ***
Ten dups, --> mostfreq.

Of course, you don't need to have Dave Hyatt's level of programming experience
to realize that Microsoft will never change the WM_CONTEXTMENU event to
mousedown -- since that would break the apps which have (unwisely) chosen to use
right-click-and-drag. What Microsoft would do instead is publish (and start
recommending the use of) the event which they're already using in Microsoft
Excel, Microsoft Publisher, Microsoft Works Spreadsheet, Microsoft Photo Editor,
etc -- the one which triggers on right-mousedown *as well as* right-click and
Shift+F10, the one which Netscape Communicator 4.x either used or imitated.

(For the record, my list *is* correct: I checked RealPlayer 7.0 again and it
does indeed open its context menus on mousedown.)
Keywords: mostfreq
Would it be possible to also pop up the context menu on the message 
generated by right-click-and-drag? (Is there such a message?) We could pop it up 
at the initial drag coordinates. This would mean both parties in this 
argument were happy, except that those right-dragging to select menu items would 
see a small "delay" in the appearance of the menu.

IMO, though, it's no big deal if this doesn't get fixed as the most useful 
quick-access command on the menu by far is "Open In New Window", and that's now 
XP middle-mouse-button.

Gerv 
While the addition of "Open in new window" to the middle mouse button is nice, 
it isn't the only context menu item I use on a regular basis.  I regularly use 
"Save image...", "Save target...", and "Copy link location..." as well.  And I 
have no middle mouse button on one of the computers I use.

Maybe a new tack is needed here.  How about a bribe?  :) First Mozilla developer 
who manages to get this changed in the tree gets $50.

I have RealPlayer 8.  They changed it to mouseup.  :)

Anyway, what would complicate the code is that there is no mousedown context
menu event.  If you want to deviate, you have to listen to all the
messages(mouse and key) by hand (which is what we did in 4.x).


Reproduced on:
2001-06-21-04, Win98 & Win2k
2001-06-18-04, Win98 & Win2k
2001-06-09-20, Win98 & Win2k
2001-06-04-04, Win98 & Win2k

So again, a few programmers are deciding the fate of a supposed 'open-source'
project.  Way to go.

I have a great deal of respect for the mozilla developers, but I'm starting to
notice many flaws with their thinking -- especially on handling controversial bugs.

And quite interesting, as has been noted by others, that this is considered
RESOLVED FIXED.  RESOLVED LATER or RESOLVED REMIND makes much more sense.

So, to those who wish to keep this option in place: who gives you the right to
decide the fate of all users?  This is open source.  At least offer a documented
hidden pref.

This bug, these users, this problem will not go away.  It is cancerous; it will
only spread and get uglier.
...adding myself to CC.  Wow, hmm, up to 12 votes now.

Common sense dictates at least nominating for nsCatfood.  Anybody?
while I don't agree with the developers, I don't really blame them.  If they
don't feel like fixing this bug, that's their parogitive.  opensource isn't,
"we'll do anything you want us to do."  it's, "here's the source code, if you
want a feature, feel free to program it yourself, and post your changes so
others may enjoy the fruit of your loins."  I'm sure someone will figure out the
focus bug and post a patch somewhere that everyone will download, except maybe
the mozilla developers.  I'm investigating it and will post here when (if) I
discover the root of the problem.  I don't really mind if the bug is fixed or
not.  I use k-meleon, which already has a workaround for this bug; but I figure
I may as well attempt to fix it for those of you that don't use k-meleon.
(Gotta love the spam!  Hehe)

Brian, it's people like you -- along with your correct line of thinking -- that
make open source work.  If I had the ability (read: skills) to program for
mozilla, I would.  You do, and you are, so kudos to you.  At least someone,
somewhere, will have the option.

So if there's anyone out there that is serious about this bug *and* can help him
out, why not give him a buzz?  It's always best to collaborate to solve these
problems, hence the open-source structure...all making sense now, isn't it?  :D
Just another comment on it..

As small as this feature seems, it is one of the things that makes netscape 
more usable.  If you use NS4 then use IE you can see the differences in 
usability.  Context menu features are there when you need them, progress 
indicators actually follow the progress of what the page is doing instead of 
just the progress of time. (what's that about, I can look at a clock on the 
wall if I want to know that) It just feels more like a tool than a program 
trying to hide stuff from you.  Taking away little things like context on mouse 
down is taking away the main reason I like Netscape, the feel of usability and 
responsivness as a tool.
With some help from Dean, I tracked down the problem.  When you right-click on 
the page, it calls CaptureMouse which redirects all mouse messages to that 
window.  In things like the bookmarks this isn't a problem because the context 
menu and the bookmark window have the same viewmanager, but on a webpage it 
doesn't work like that.  It turns out we don't even have to call capturemouse on 
right mouse down, since there's no code that relies on that (really its only use 
is right-click-and-drag, which, as others have mentioned, will not be 
implemented in mozilla).  I also had to change the popup listener code that 
relied on the context menu appearing on mouse up.
While I was at it, I added a pref |contextmenu.open.on_mouse_down|.  It defaults 
to false, and context menus behave exactly as they do now; but if you change it 
to true, they act like the context menus in NS 4.
I've tested the patch quite a bit, everything seems to work fine with it.  
Things that are broken also happen to be broken in the daily builds, so that's 
not my problem :)
Hey Binarycowboy, I think I speak for a lot of people when I say I'd like to buy
you a beer!
forget the beer, I want my $50 from charlesc-mozilla@qcc.sk.ca :)
Nice! Is this somthing that the developers will implement?  I don't see why not
if it defaults to the current behavior and doesn't cause any other problems.
I'm not qualified to review this code, but you will probably want to do 
something with pref listeners instead of checking the pref on every context menu 
popup. Maybe. Anyway, find who owns this code and ask them to have a look.

Adjusting stuff...

Gerv
Status: RESOLVED → REOPENED
OS: Windows NT → All
Resolution: FIXED → ---
Summary: Make context menus display on button down instead of up → Add option to make context menus display on button down
I'm going to re-close this bug, but mark it as a duplicate of bug 89308.  This
bug has become too polluted to be of any use.  Please see my comments from today
in 89308.

*** This bug has been marked as a duplicate of 89308 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
OS: All → Windows 2000
Resolution: --- → DUPLICATE
Verified dupe
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: nobody → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: