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)

x86
Windows 2000
enhancement

Tracking

()

VERIFIED DUPLICATE of bug 89308
Future

People

(Reporter: dean_tessman, Unassigned)

References

Details

Attachments

(1 file)

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 ago24 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: 24 years ago24 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: 24 years ago24 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: 24 years ago23 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: