Closed Bug 16766 Opened 25 years ago Closed 23 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 → 23 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.