Closed Bug 16766 Opened 25 years ago Closed 24 years ago

xpPopups and context menus can't be used with a single drag

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: mpt, Assigned: blizzard)

References

Details

(Whiteboard: [nsbeta3-])

Attachments

(3 files)

Here it is.
1.30 KB, patch
Details | Diff | Splinter Review
Here's the patch.
3.73 KB, patch
Details | Diff | Splinter Review
Patch for Linux/GTK -- make context menu items select on drag
3.34 KB, patch
Details | Diff | Splinter Review
To use a context menu, you need to Ctrl+click to activate the menu (click-and- hold doesn't work, but that's probably a separate bug), and then you need *another* click to select the item. OBSERVED ON apprunner for MacOS, 1999-10-18 build TO REPRODUCE In apprunner, Ctrl+drag in a Web page, in an attempt to bring up the context menu and select an item. WHAT HAPPENS The context menu appears, but the mouse drag selects text (and may even scroll the Web page) under the menu. The mousebutton must be released before the menu starts highlighting items in response to the mouse pointer, and another click is required to actually select an item. WHAT SHOULD HAPPEN The context menu should take focus from its parent window, and a menu item should be selectable by letting the mouse button go (with or without Ctrl still down) over the item. So a context menu should be usable with two clicks (as currently), or with one drag. -- mpt (additional keywords: popup, right-click)
reoproduced in today's opt bits, reassigning to saari as p3 for m12
Assignee: trudelle → saari
Target Milestone: M12
mass-moving all m12 bugs to m13
QA Contact: claudius → elig
[Contextual menu bug --- QA Assigning to self.]
Component: XP Toolkit/Widgets → XPMenus
QA Contact: elig → sairuh
reassigned QA contact to me & updated component.
Target Milestone: M13 → M15
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Changing OSes to All. This isn't working on Windows either (build 1999122308), although Windows doesn't have the focus problem.
Assignee: saari → pinkerton
ooh, this one is going to suck. Taking menu/popup bugs.
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
*** Bug 21549 has been marked as a duplicate of this bug. ***
pinkerton: it may be a good idea to fix bug 17159 before this bug, to avoid possible duplication of effort.
Summary: Context menus can't be used with a single drag → [4.xP] Context menus can't be used with a single drag
From bug 21549, the same behaviour is being requested (and exists in 4.x) for right-click-drag-mouseup on other platforms as for ctrl-click-drag-mouseup on a Mac, to select an item on a control menu.
bulk accepting xpmenu/popup bugs. sigh.
Status: NEW → ASSIGNED
*** Bug 18726 has been marked as a duplicate of this bug. ***
*** Bug 19232 has been marked as a duplicate of this bug. ***
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
*** Bug 25211 has been marked as a duplicate of this bug. ***
This one doesn't look like it would be too difficult to address. Unfortunately, I've looked through the code for NS_MOUSE_RBUTTON_DOWN to find where the context menu is instantiated, but I haven't found much. Can anyone give me a hint as to where to start?
Summary: [4.xP] Context menus can't be used with a single drag → Context menus can't be used with a single drag
Well, I'm going to have to pretty much give up on this one. I've tracked the popup menu process through from, as far as I can tell, start to finish, and everything that I'm watching happens before MouseUp. All I'm trying to find is what happens on MouseUp that sets the capture to the context menu instead of the underlying window, but I've not had much luck.
I fixed this on mac by munging with our event dispatcher. It was always sending the mousemoves to the window with the mousedown, which was obviously not the case anymore when a context menu (or any xul popup) popped up. Just FYI.
Is this a Mac-specific fix, or will it apply to all platforms?
each platform has platform-specific event dispatch problems. i fixed them on mac, so now this bug is linux/win32 only.
Cool. If you give me a hint as to where to start looking, I'll see if I can knock this off on Win32. Oh, and if you want to give me a brief pointer to what you did on the Mac, it'd probably save me a couple of hours.
my fixes on mac were in mozilla/widget/src/mac/ nsMacEventHandler::ConvertOSEventToMouseEvent mainly the focussed on making sure the event was sent to the popup and not the widget where the mouseDown occurred. win32/linux will probably be different since they handle mouse capture in a totally different way (at the OS level) but looking in nsWindow/nsWidget will probably be a good place to start.
I added a couple of lines of code and now this works for me under Win32. But it's gotta be a hack. It's just ... got... to... (doing his best William Shatner). But I can't break it. If I combine this with my patch for Bug 17159, context menus work beautifully for me under Win32. Anyway, feel free to look at the patch and laugh. But just make sure that you tell me when you're done laughing.
Attached patch Here it is. — — Splinter Review
Adding myself to the cc: list.
Keywords: patch
One thing that I noticed when working on this bug is that when any menu is active, be it context or not, the pointer still responds to whatever's under it. For example, if I go to mozilla.org, drop down the tasks menu, then move my pointer over some text the pointer changes to an I-beam. If I mouse over a link, the pointer becomes the finger and the status bar displays the url. In both cases the pointer should remain the default pointer. This is unrelated to anything that I've done. Off to enter a new bug...
dean, i spoke with rod this morning and he doesn't feel comfortable with the patch until we know why the mouse capture switching doesn't work with right- mouse, but does with left-mouse. would it be possible for you to investigate this and get enough info so we know what is going on here? I'm too busy working on positioning issues, and this isn't pdt+ so I can't justify spending a lot of time on it, but everyone in my group (including my manager) wants this to get in for beta! thanks!!!!
Don't worry, I'm not overly comfortable with the fix, either. What do you mean when you say that it works for left-mouse? Off the top of my head (source is at home), here's why I don't think it works. 1. right-button down; 2. context menu is created; 3. capture set to context menu; 4. capture set to browser window; 5. end of right-button down processing; 6. right-button up; 7. capture released from browser window, leaving the context menu with capture; If this is the case, my patch removes step 4.
but doesn't it also remove step 3? or is that capture done elsewhere? by "it works for the left-mouse button" i mean that things like the bookmarks popup and other xul popups work with left-click-drag. It's only context menus that don't seem to behave with a right-click-drag. I don't see how the code could be any different, though, in terms of how it treats the two events.
I'm not sure where the capture in 3 is done. Actually, this is one thing that I never really figured out. The one difference between the left-mouse drag working for the bookmarks menu is that this is initiated by clicking on an nsMenuBarFrame or something, isn't it? And the context menu is initiated by a click on an nsWindow. Maybe there's something special done by the menu bar. Perhaps in ToggleMenuActiveState() in nsMenuBarFrame.cpp. Sorry if I'm way off here. Things are really busy today. But I thought I'd throw out a few suggestions.
OK, I'm still thinking that what I described in those 7 steps is what's happening. If you comment out the CaptureMouse(PR_FALSE) in the button up switch ChildWindow::DispatchMouseEvent of nsWindow.cpp, the menu never receives messages. The MouseOver, etc., messages in nsMenuListener still fire, but they're stolen by the nsWindow. Perhaps something that would be a little less hacky would be similar to my patch, but only not set the capture to the nsWindow if a popup menu with type of "context" is active. Because it looks like by the time that processing gets to DispatchMouseEvent(), the context menu has been created. But I can't figure out how to check this. If this sounds like a better approach, then I'll need a quick hint on how to find out if a context menu is active. I'm going to keep looking...
*** Bug 31016 has been marked as a duplicate of this bug. ***
*** Bug 30264 has been marked as a duplicate of this bug. ***
moving all defects not directly related to P0 beta2 features off to M18.
Target Milestone: M15 → M18
*** Bug 32817 has been marked as a duplicate of this bug. ***
Wanna hear a pisser? The context menus in the Manage Bookmarks window and in the Bookmarks sidebar work properly.
Try this one on for size. What I do is release the capture on the window that's right-clicked on when the popup menu is first being activated, and before it's shown. It's a lot of code, but it all looks necessary. I can't comment on it for sure, because I took it almost verbatim from somewhere else. And it's XP, so it should address all platforms at once. The only thing that I haven't been able to get working is the active link coloring should disappear when the menu disappears. For an example, right-click a link and then press Esc. This is a symptom of the larger problem, being that the window only receives NS_MOUSE_RIGHT_BUTTON_DOWN but never NS_MOUSE_RIGHT_BUTTON_UP. One solution is to, in the same place that I do the funky stuff above, send an NS_MOUSE_RIGHT_BUTTON_UP event to the same window that we just released capture from. But I couldn't figure out how to do that. It would be easy in Windows (!) - just SendMessage(...). Can anyone offer a tip as to how to accomplish this in XPToolkit? I looked into DispatchMouseEvent, but didn't get very far.
Blocks: 31302
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
*** Bug 35387 has been marked as a duplicate of this bug. ***
*** Bug 36345 has been marked as a duplicate of this bug. ***
*** Bug 36345 has been marked as a duplicate of this bug. ***
*** Bug 33059 has been marked as a duplicate of this bug. ***
*** Bug 33059 has been marked as a duplicate of this bug. ***
I just voted for this bug, so I'll add a comment. The ability to click, flick, and release to go back is really convenient. This is the Netscape 4 behavior, and I much prefer it over the IE behavior. There is a quirk in mozilla (M15) that may be related: If I right click for a context menu then, before the menu appears, move the mouse to where the (eg) "back" option will be; then when the menu appears, the mouse is already over "back", but "back" is not highlighted. If I move the mouse a pixel, "back" is highlighted. This is pretty disorienting.
Let me add to my last comment. It's a little weirder than I said. Again, right click and move the mouse over "back" before the menu appears. Normally, as I said before, "back" is initially not highlighted, but moving the mouse a pixel causes it to be highlighted. Further, if you don't move the mouse after the menu appears, clicking works even though "back" is not highlighted. BUT--if you arrange that when the menu appears, the mouse is around the middle of the empty space in the menu to the left of the word "Back", the above is not true. There is a small window (roughly the center quarter of said empty space) in which you can move the mouse around without the highlight kicking in. Move out of the window, and the highlight comes on. Also, while you are in the window, clicking doesn't work--there is no response to clicks. I'm using the M15 Linux build. Please tell me if this should be a separate bug.
I'm not sure if this is understood or not, but the place in the Linux/GTK code where the "capture" takes place is the "sButtonMotionTarget" hack in widget/src/gtk/nsWidget.cpp. That is, when the mouse button goes down, "sButtonMotionWidget" gets set to the target widget. From then on, all motion, enter, and leave events up to and including the next mouse button up event get redirected to that target widget. If you comment out: sButtonMotionTarget = this; in nsWidget::OnButtonPressSignal, the context menu works as expected, but this probably breaks other things. I note that the Windows widget code has a sophisticated scheme based on a MouseTrailer class to get Enter and Leave events to the right parties. Perhaps this is what we need here?
Adding to my last comment... In particular, Dean's patch (attachment 7030 [details] [diff] [review]) doesn't help Linux/GTK. It just generates an extra CaptureMouse(false) without a matching CaptureMouse(true)---this gives a "critical" (though harmless) GDK error as GDK tries to ungrab a non-grabbed pointer, and it doesn't affect the value of sButtonMotionTarget, so the mouse is still effectively captured. Presumably this works with Windows because Windows does an implicit CaptureMouse(true) in ChildWindow::DispatchMouseEvent whenever a mouse button goes down, so the extra CaptureMouse(false) is actually having a useful effect.
I've done a little more work on this problem, and I've figured out the fundamental reason that mouse capture "works" with regular menu bars but doesn't work with right-clicking a context menu. It boils down to the fact that the frame constructed by the XUL <browser> element (or one of its child frames, perhaps) uses a *different view manager* than the rest of the browser frames, including the frame constructed by the <popup>. When I left-press on the regular menu bar, the platform-specific toolkits jump through various hoops to direct mouse events to a particular widget until the mouse button is released. However, every widget's view handles the mouse event by passing it to its view manager---the view manager then dispatches the event to the appropriate view enclosing the current point. Since all menubar components share the same view manager, it doesn't matter which widget gets the mouse event. It gets passed up to the same view manager which directs it to the view containing the mouse cursor. However, when I right-press on browser content to get a context menu, what happens? The platform-specific toolkits try to direct all mouse events to a widget associated with the <browser> element. However, these elements have a different view manager, one that's unaware of the context menu view. Even when the mouse is moving over the context menu, the events are passed to some browser widget, to the browser's view manager, and to a view managed by that view manager, which will *never* be the context menu view. To see that this is the case, you can do some XUL fiddling. In "navigator.xul", search for the <browser ...> element, and add a box after it like so: <box context="context" flex="100%"> <browser type="content-primary" id="content" src="about:blank" flex="100%"/> <box flex="100%"/> <!-- *** ADD THIS BOX *** --> </box> When you start up your browser, you'll discover that right-dragging the context menu doesn't work in the <browser> element, but it works in the empty <box> you've added. The new <box> has the same view manager as the <popupset>, so mouse events directed to the <box>'s widget find their way to the context menu view. Mouse grabbing, in general, seems a bit broken. Every platform-specific widget set is using slightly different semantics for auto-grabbing, and there's no working external control interface. nsWindow::CaptureMouse might work on some platforms, but not on Linux/GTK---it doesn't undo the implicit grab performed by the sButtonMotionTarget mechanism. The platform-independent mouse grabbing via nsFrame::CaptureMouse "works" at a view-manager level, but its semantics aren't clear. It doesn't really "grab" the mouse, it merely directs a particular view manager to pass mouse events that somehow reach it to a specific managed view. If events go to a different view manager, the grab is ineffective. Does anyone know what the semantics (or at least usage guidelines) of nsWindow::CaptureMouse, nsViewManager::GrabMouseEvents, and nsFrame::CaptureMouse are supposed to be?
This would also seem to explain why the click-and-drag works properly in the Manage Bookmarks window and Bookmarks sidebar panel. Any idea what the fix is, then? Maybe on a right-click, we can grab the context menu that's created, get its view manager, and then use GrabMouseEvents on it? That is if GrabMouseEvents does what it sounds like it does...?
Infuriatingly, that won't work. Because the grab only works at a per-view-manager level, the events (captured by the platform-dependent toolkits) are directed to a browser widget which passes them to the browser view manager. The *browser* view manager isn't capturing mouse events, though---only the context menu's view manager is capturing them---so the browser view manager just passes it off to the innermost enclosing browser view, ignoring the mouse capture entirely. What we'd need to do is get our hands on the browser widget that received the mouse button down event; *it's* view manager will be the browser view manager which receives all mouse events (up to including the next mouse button up) from the browser widget, which gets them from the implicit grab performed by the platform-dependent toolkits. Then, if we could, we'd tell *that* view manager to grab mouse events on behalf of a view (namely, the context menu view) that it doesn't own! This seems very broken, since presumably a view manager shouldn't care about views it doesn't manage. Still, it might work: it's even possible that the context menu has jumped through enough hoops that the event positioning would work out right. I think a better solution is to fix the toolkits---either by overloading the nsWindow::CaptureMouse interface or by introducing a new method---so that it's possible to reliably release all toolkit-level mouse captures, either explicit (someone else called nsWindow::CaptureMouse) or implicit (when the mouse button goes down and the toolkit starts directing all mouse events to the pressed widget). Then, when the context menu listener sees a right mouse button down, it can decide to release the implicit mouse grab right then and there. This also means we won't have to make the right button "magical": higher-level code can decide when releasing an implicit grab is warranted.
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
*** Bug 42164 has been marked as a duplicate of this bug. ***
*** Bug 42570 has been marked as a duplicate of this bug. ***
Summary: Context menus can't be used with a single drag → xpPopups and context menus can't be used with a single drag
nominating for beta3, we need to nail this one once and for all.
Keywords: nsbeta3
*** Bug 41643 has been marked as a duplicate of this bug. ***
13 duplicates --> mostfreq
Keywords: mostfreq
Can someone remove the "patch" keyword for now, as neither of my patches work for all cases?
okey-dokey -- removing patch keywords. [Side-note: claudius can you set Dean up with the right permissions to do this himself (since I lack the powers to do so :-]).
Keywords: patch
Keywords: correctness
Priority: P3 → P4
Whiteboard: nsbeta3+
Re:side-note So you have spoken as so it has been done.
Re: side note - thanks, by the way.
Whiteboard: nsbeta3+ → [nsbeta3+]
*** Bug 47794 has been marked as a duplicate of this bug. ***
*** Bug 47899 has been marked as a duplicate of this bug. ***
*** Bug 48059 has been marked as a duplicate of this bug. ***
So Kevin, am I thinking along the same lines as you? In the browser's view maanager, check if there's a context menu currently open. If there is, pass all mouse messages through to the context menu's view manager.
Please note that we are not committing to fix P4/P5 bugs for N6, although we could still work on a fix in priority order, or take a patch.
Target Milestone: M21 → M18
Then this bug really shouldn't be P4.
This was working on Windows but is shadowed by the fix for bug 48838, which changed the context menu behavior to standard win32 behavior (that is, the context menu appears onmouseup rather than onmousedown as before). So if this is working on Mac and Linux now, we can mark this fixed...
ok
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
On a 8/25 morning CVS pull on linux one-drag operation of context menus still does not work. Reproduction steps: * press and hold right mouse button * move pointer over context menu items - they will not highlight, and if you happen to pass over a link in the underlying page the status message will be updated like an ordinary mouse-over Tested on linux using fvwm2.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
linux --> pav
Assignee: pinkerton → pavlov
Status: REOPENED → NEW
OS: All → Linux
Hardware: All → PC
Changing OS back to All and resolution to WONTFIX, given the discussion in bug 49844. Might as well add a dependency on 49844 while I'm at it.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Depends on: 49844
OS: Linux → All
Resolution: --- → WONTFIX
Reopening and setting back to Linux only (although still P4/not committed). For popups this works on all platforms (mac/linux/win32) (try attachments or threadPane column selection in mailnews for example). For context-menus, this works on Mac (you can get the context menu, drag and then release over a menuitem to select it). Since we are going with win32 platform convention, where a context menu comes up on mouseup, this cannot work for context menus (a second click is required, but that is the same behaviour as in other windows apps). However, on Linux, the context menu comes up on mousedown, but the menuitems in the context menu are not selected until you release the mouse (two clicks are required). This is counter to platform convention, where other apps allow you to do context-click/drag/release-to-select.
Status: RESOLVED → REOPENED
OS: All → Linux
Resolution: WONTFIX → ---
I don't agree but it doesn't sound like it's going to change (bug 49844). I'm out.
Mass-moving P4/P5 bugs to Future milestone. We just don't have any time left for these, although we could still consider taking a good patch. Adding Helpwanted keyword.
Keywords: helpwanted
Target Milestone: M18 → Future
nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
Removing nsbeta3- and requesting reevaluation of this bug. It was mass-moved to future, but appears on the Most Frequently Reported bugs list. I therefore believe it should not have been P4 or P5, and so should not have been moved to Future. Please confirm that you believe this most frequently reported bug is indeed low-priority. Gerv
Whiteboard: [nsbeta3-]
confirming nsbeta3-/future. The mostfreq status is deceptive, since it is mostly from when this was a problem on Windows. This defect is just not worth the time and risk. In order to ship this year, which we *must* do, we cannot afford to make unnecessary changes to the codebase. IMO, making such changes at this time could endanger the future of the entire codebase. removing helpwanted.
Keywords: helpwanted
Whiteboard: [nsbeta3-]
A little melodramatic, Peter, but fair enough :-) Removing mostfreq, as the Frequently Reported behaviour has been fixed. Gerv
Keywords: mostfreq
Not that I disagree but I find it interesting that changes to the codebase were made two or three weeks ago to change the context menus from button-down to button-up.
That caught my eye too, and is another of many examples of the kind of churn that has to stop if we are to have any hope of ever shipping this product. Gervase may think my comment melodramatic, but I'm just plainly saying what I feel strongly, based on many years of shipping products.
It was more the image engendered by: "IMO, making such changes at this time could endanger the future of the entire codebase." of the entire Mozilla codebase, and all mirrors of it, suddenly vanishing into thin air overnight because someone had made too big a change, which amused me :-) "Ye cannae make a change like that, Cap'n - she wouldnae hold together!" Anyway, back to some real work... Gerv
Peter, I agree. That's why it surprised me that that change made it in so eralatively late in the game.
I didn't mean that existing code would disappear, but if Netscape failed, mozilla.org would instantly lose most of its support. The *future* of the codebase would be then be vastly different, wouldn't it?
I know you didn't mean that :-) It was just an amusing thought, that's all. Never mind :-) Gerv
*** Bug 53526 has been marked as a duplicate of this bug. ***
*** Bug 54290 has been marked as a duplicate of this bug. ***
This would actually be fixed if we changed things to just have one view manager per window ... a change that would fix a number of other problems too.
*** Bug 58065 has been marked as a duplicate of this bug. ***
*** Bug 59472 has been marked as a duplicate of this bug. ***
*** Bug 59721 has been marked as a duplicate of this bug. ***
*** Bug 60145 has been marked as a duplicate of this bug. ***
Restoring mostfreq keyword: 16 of the duplicates of this bug were filed specifically for Linux. (Of the remainder, 1 -- not counting the original report -- was for Mac OS, and the other 5 were for Windows and therefore really dups of bug 49844.)
Keywords: mostfreq
A patch follows (effects "gtk" only). Sigh... I simply drop that damn sButtonMotionTarget processing in gtk/nsWidget whenever gtk/nsWindow captures the mouse (via CaptureMouse or NativeGrab called by nsCaptureRollupEvents). Ideally, the CaptureMouse/NativeGrab code could be smart enough to set up the sButtonMotionTarget processing for the grabber, but I can't figure out what to set sButtonMotionTarget to. The obvious, setting it to the nsWindow doing the CaptureMouse(PR_TRUE), doesn't work---whichever nsWidget actually gets the events, it's not the nsWindow that captures the mouse. If someone could explain to me how nsIFrame::CaptureMouse, nsIWidget::CaptureMouse, and nsWindow::sGrabWindow/sIsGrabbing, are supposed to interact, how the GTK event-handling model (spread over nsWidget, nsWindow, and nsGtkEventHandler) is supposed to work, and how the superwin, mozarea, mozbox, shell, and every other bloody widget flying around are supposed to do whatever it is they're supposed to do (in Mozilla and in embedded code), I could actually attempt a better fix. It's just beyond my complexity horizon. I haven't looked through the documentation list in a while; maybe I'll try there. Anyway, it looks like sButtonMotionTarget processing doesn't accomplish much right now. Or rather, whatever it accomplishes is undone by the post-toolkit event processing. For example, if you left drag the normal menubar menus (in Mozilla or even Netscape final), the "back" and "reload" buttons still respond to enter/leave, tooltips still pop up, and so on. Even though the sButtonMotionTarget has captured all mouse events, the nsViewManager is still directing them off to all sorts of widgets. The only thing sButtonMotionTarget processing seems to accomplish in the current setup is making sure that events between button down and button up go to the same view manager, even if you move into a view managed by a different manager. That's probably good for some purposes, but it's what causes this content-menu bug, as I explained somewhere way up above. Anyway, I guess what I'm trying to say is that even though my patch "breaks" the sButtonMotionTarget processing, it doesn't actually have a visible effect, and context menus will work the way they're supposed to. Patch follows.
*** Bug 62676 has been marked as a duplicate of this bug. ***
pav -- can you have a look at the attached patch. Thanks.
Keywords: patch, review
Priority: P4 → P3
Target Milestone: Future → ---
->moz0.8, increasing priority to p2 to handle patch
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
blizzard? care to take a look at this too?
Patch #19719 seems to make drag-select work with context menus on linux.
*** Bug 67554 has been marked as a duplicate of this bug. ***
*** Bug 67554 has been marked as a duplicate of this bug. ***
r=pavlov, sr=blizzard on this. Sorry that it took so long to look at it. The fix looks right. Personally, I'm amazed that you were able to get that to work considering the maze of event paths on linux. I'll check this in in a few minutes.
-> blizzard@mozilla.org for checkin
Assignee: pavlov → blizzard
Status: REOPENED → NEW
Checked in.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: