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)
Tracking
()
Future
People
(Reporter: dean_tessman, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
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
Comment 1•24 years ago
|
||
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?
Comment 2•24 years ago
|
||
(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.
Reporter | ||
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
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
Reporter | ||
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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.
Reporter | ||
Comment 12•24 years ago
|
||
You mentioned, though, that this fixes other bugs. Which ones would we have to
keep in mind?
Comment 13•24 years ago
|
||
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.
Reporter | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
no pref! no pref! i'll have to mark those new bugs with the pref on won't fix.
Reporter | ||
Comment 16•24 years ago
|
||
Mike - why? Future bugs that need the mouse-up behavior?
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
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.
Reporter | ||
Comment 19•24 years ago
|
||
*** Bug 50771 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
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.
Reporter | ||
Comment 21•24 years ago
|
||
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!
Comment 22•24 years ago
|
||
I've filled in a bug report for the interaction between x-mouse and context
menus on NT in bug #50798
Comment 23•24 years ago
|
||
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")?
Updated•24 years ago
|
Whiteboard: Being discussed in n.p.m.ui
Reporter | ||
Comment 24•24 years ago
|
||
*** Bug 52169 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
*** Bug 56378 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
(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.
Comment 27•24 years ago
|
||
> I played around with a lot of apps, and it seems 50/50.
Could you name some of those apps? Might be interesting.
Comment 28•24 years ago
|
||
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.
Comment 29•24 years ago
|
||
[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.]
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
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.
Comment 33•24 years ago
|
||
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.
Comment 34•24 years ago
|
||
recall that doing things this way fix _many_ serious focus-related bugs. You can
have those back if you like.
Comment 35•24 years ago
|
||
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).
Comment 36•24 years ago
|
||
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.
Comment 37•24 years ago
|
||
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.
Updated•24 years ago
|
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Comment 38•24 years ago
|
||
> 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.
Reporter | ||
Comment 39•24 years ago
|
||
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.
Reporter | ||
Comment 40•24 years ago
|
||
Hyatt: Found it - FireFocusOnTargetContent().
So that just leaves bug 16766, or maybe we should open a new one for Windows.
Comment 41•24 years ago
|
||
now that bug 16766 has been fixed, does that mean we can fix this one too?
Reporter | ||
Comment 42•24 years ago
|
||
Brian, sorry buy no. The fix in 16766 is for Linux only. That part of the code
is a completely different world than Windows.
Comment 43•24 years ago
|
||
So then has a new bug been filed for windows?
Or should bug 16766 be reopened with "windows" added?
Reporter | ||
Comment 44•24 years ago
|
||
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.
Comment 45•24 years ago
|
||
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
Comment 46•24 years ago
|
||
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 → 24 years ago
Resolution: --- → WONTFIX
Comment 47•24 years ago
|
||
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.
Comment 48•24 years ago
|
||
pinkerton: are you sure about the WM_CONTEXTMENU thing? The reason I ask is
because nsIContextMenuListener::OnShowContextMenu fires on mouse down.
Comment 50•24 years ago
|
||
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.
Comment 51•24 years ago
|
||
Can we remove the wontfix status? It makes me the shudder...
Comment 52•24 years ago
|
||
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.
Comment 53•24 years ago
|
||
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.
Comment 54•24 years ago
|
||
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.
Comment 55•24 years ago
|
||
we are using the win32 WM_CONTEXTMENU event. Period. Done. This conversation is
over.
Comment 56•24 years ago
|
||
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 → ---
Comment 57•24 years ago
|
||
Unauthorized Reopen.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
Comment 59•24 years ago
|
||
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
Comment 60•24 years ago
|
||
Reassigning to our friend, nobody.
Gerv
Assignee: pinkerton → nobody
Status: REOPENED → NEW
QA Contact: jrgm → nobody
Comment 61•24 years ago
|
||
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: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 62•24 years ago
|
||
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
Comment 63•24 years ago
|
||
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.
Reporter | ||
Comment 64•23 years ago
|
||
Shouldn't this be closed as WONTFIX, not FIXED?
Reporter | ||
Comment 65•23 years ago
|
||
*** Bug 85530 has been marked as a duplicate of this bug. ***
Comment 66•23 years ago
|
||
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.
Reporter | ||
Comment 67•23 years ago
|
||
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).
Comment 68•23 years ago
|
||
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.
Reporter | ||
Comment 69•23 years ago
|
||
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.
Comment 70•23 years ago
|
||
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.
Comment 71•23 years ago
|
||
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.
Comment 72•23 years ago
|
||
<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?
Comment 73•23 years ago
|
||
Oops, I read it wrong. You said no one prefers the current behaviour...
Reporter | ||
Comment 74•23 years ago
|
||
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.
Comment 75•23 years ago
|
||
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).
Reporter | ||
Comment 76•23 years ago
|
||
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
Comment 77•23 years ago
|
||
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 :)
Comment 78•23 years ago
|
||
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.
Comment 79•23 years ago
|
||
> 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
Comment 80•23 years ago
|
||
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.
Comment 81•23 years ago
|
||
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.
Comment 82•23 years ago
|
||
WE ARE NOT CHANGING THIS IN MOZILLA. GET OVER IT.
Comment 83•23 years ago
|
||
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!
Comment 84•23 years ago
|
||
> 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.
Comment 85•23 years ago
|
||
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.
Reporter | ||
Comment 86•23 years ago
|
||
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.
Comment 87•23 years ago
|
||
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).
Comment 88•23 years ago
|
||
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.
Comment 89•23 years ago
|
||
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.
Comment 90•23 years ago
|
||
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).
Comment 91•23 years ago
|
||
> > 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.
Comment 92•23 years ago
|
||
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...
Comment 93•23 years ago
|
||
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.
Comment 94•23 years ago
|
||
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.
Comment 95•23 years ago
|
||
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.
Comment 96•23 years ago
|
||
Let's go to Redmond and hack the damn "OS behavior" for our own good.
Comment 97•23 years ago
|
||
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!
Comment 98•23 years ago
|
||
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).
Comment 99•23 years ago
|
||
That's the whole point of listening to the message. If Windows does change the
behavior, yes, we'll pick it up automatically.
Comment 100•23 years ago
|
||
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*.
Comment 101•23 years ago
|
||
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.
Comment 102•23 years ago
|
||
*** Bug 83764 has been marked as a duplicate of this bug. ***
Comment 103•23 years ago
|
||
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
Comment 104•23 years ago
|
||
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
Comment 105•23 years ago
|
||
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.
Comment 106•23 years ago
|
||
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).
Comment 107•23 years ago
|
||
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.
Comment 108•23 years ago
|
||
...adding myself to CC. Wow, hmm, up to 12 votes now.
Common sense dictates at least nominating for nsCatfood. Anybody?
Comment 109•23 years ago
|
||
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.
Comment 110•23 years ago
|
||
(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
Comment 111•23 years ago
|
||
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.
Comment 112•23 years ago
|
||
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 :)
Comment 113•23 years ago
|
||
Comment 114•23 years ago
|
||
Hey Binarycowboy, I think I speak for a lot of people when I say I'd like to buy
you a beer!
Comment 115•23 years ago
|
||
forget the beer, I want my $50 from charlesc-mozilla@qcc.sk.ca :)
Comment 116•23 years ago
|
||
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.
Comment 117•23 years ago
|
||
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
Reporter | ||
Comment 118•23 years ago
|
||
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: 24 years ago → 23 years ago
OS: All → Windows 2000
Resolution: --- → DUPLICATE
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.
Description
•