Closed Bug 50297 Opened 24 years ago Closed 23 years ago

Tree controls improperly consuming mouse events

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME
mozilla0.9

People

(Reporter: mkaply, Assigned: hyatt)

References

Details

(Keywords: access, arch, helpwanted)

In trying to implement context menus on Windows/OS/2, I have discovered that 
tree controls appear to be improperly consuming mouse button messages.

In Windows, the WM_CONTEXTMENU is the result of a rbuttondown/rbuttonup event 
getting routed to the default window procedure which causes the message to be 
generated.

This processing works find in the main browser window and other windows within 
the browser. This can be verified by using the WinSpy utilities to spy the 
messages.

However, in tree views, this does not happen.

I have debugged the problem considerably, and have traced the problem to a call 
to HandleEventSubType in nsEventListenerManager::HandleEvent. After this call, 
the event flags are changed to cause this event to be NO_DEFAULT.

My guess (a total guess) is that there is Javascript code involved in the tree 
views that is handling the mouse click for other reasons and returning true.

I don't know enough about the JS event handling to continue debugging.

I debugged this by setting a break point at the call to CheckForAndDispatchClick 
in nsEventStateManager.cpp around line 897.

Here's the call stack:

nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x036e3c40, 
nsIDOMEvent * 0x038c0224, nsIDOMEventTarget * 0x036e3fa0, unsigned int 
0x00000004, unsigned int 0x00000002) line 714
nsEventListenerManager::HandleEvent(nsIPresContext * 0x0365d8e0, nsEvent * 
0x0012f3c4, nsIDOMEvent * * 0x0012f2f0, nsIDOMEventTarget * 0x036e3fa0, unsigned 
int 0x00000002, nsEventStatus * 0x0012f754) line 984 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x036e3f90, nsIPresContext * 
0x0365d8e0, nsEvent * 0x0012f3c4, nsIDOMEvent * * 0x0012f2f0, unsigned int 
0x00000002, nsEventStatus * 0x0012f754) line 3313
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0372d8d0, nsIPresContext * 
0x0365d8e0, nsEvent * 0x0012f3c4, nsIDOMEvent * * 0x0012f2f0, unsigned int 
0x00000001, nsEventStatus * 0x0012f754) line 3321 + 39 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f3c4, nsIView * 0x00000000, 
nsEventStatus * 0x0012f754) line 4028 + 45 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x0367dd70, nsEvent * 
0x0012f3c4, nsIFrame * 0x02ba7df8, nsIContent * 0x0372d8d0, nsEventStatus * 
0x0012f754) line 4009 + 18 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x037393b0, nsIPresContext * 0x0365d8e0, nsMouseEvent * 0x0012f864, 
nsEventStatus * 0x0012f754) line 1816 + 59 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x037393b8, 
nsIPresContext * 0x0365d8e0, nsEvent * 0x0012f864, nsIFrame * 0x02ba7df8, 
nsEventStatus * 0x0012f754, nsIView * 0x03742480) line 897 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f864, nsIView * 0x03742480, 
nsEventStatus * 0x0012f754) line 4048 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x0367dd74, nsIView * 0x03742480, 
nsGUIEvent * 0x0012f864, nsEventStatus * 0x0012f754, int 0x00000000, int & 
0x00000001) line 3963 + 23 bytes
nsView::HandleEvent(nsView * const 0x03742480, nsGUIEvent * 0x0012f864, unsigned 
int 0x00000008, nsEventStatus * 0x0012f754, int 0x00000000, int & 0x00000001) 
line 787
nsView::HandleEvent(nsView * const 0x03742e00, nsGUIEvent * 0x0012f864, unsigned 
int 0x00000008, nsEventStatus * 0x0012f754, int 0x00000000, int & 0x00000001) 
line 760
nsView::HandleEvent(nsView * const 0x0367c5c0, nsGUIEvent * 0x0012f864, unsigned 
int 0x0000001c, nsEventStatus * 0x0012f754, int 0x00000001, int & 0x00000001) 
line 760
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x0367c7a0, nsGUIEvent * 
0x0012f864, nsEventStatus * 0x0012f754) line 1429
HandleEvent(nsGUIEvent * 0x0012f864) line 69
nsWindow::DispatchEvent(nsWindow * const 0x03742cc4, nsGUIEvent * 0x0012f864, 
nsEventStatus & nsEventStatus_eIgnore) line 614 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f864) line 635
nsWindow::DispatchMouseEvent(unsigned int 0x00000140, nsPoint * 0x00000000) line 
3805 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x00000140, nsPoint * 0x00000000) 
line 4012
nsWindow::ProcessMessage(unsigned int 0x00000205, unsigned int 0x00000000, long 
0x0178006d, long * 0x0012fbe0) line 2933 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x23050236, unsigned int 0x00000205, unsigned int 
0x00000000, long 0x0178006d) line 883 + 27 bytes
USER32! 77e7124c()
Status: NEW → ASSIGNED
Target Milestone: --- → Future
So is this preventing context menus from working at all in trees, or just 
WM_CONTEXTMENU?
Currently, Mozilla context menus display based on mouse events.

What I have coded is the ability for platforms that support a context menu
notification message (so far Windows and OS/2) to use it to display context
menus (this allows things like the Windows Menu button and keyboard shortcuts to
work)

On tree views only, the WM_CONTEXTMENU never gets created by the OS in response
to the mouse events.

So I could use Shift+F10 to display context menus in tree views, but never the
right mouse button.

It worked in other areas of the browser.

So in summary, this is preventing WM_CONTEXTMENU in trees which is preventing me
from dropping code that makes context menus work a lot better on Windows and OS/2.
So this is blocking bug 36665 then?
If my suggestion for how to fix 36665 were used, then yes. :)

If this bug is fixed, I already have code to fix 36665.
hyatt: can you find someone to look into this?
Marking as a blocker of bug 36665 based on Michael's comments.
Blocks: 36665
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Target Milestone: Future → mozilla0.9
This doesn't seem to be a problem anymore.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Mike, are you sure you were looking at a Tree and not the new Outliner?  I think
the thread pane in mail/news now uses Outliner.  Just want to make sure.
the folder pane in mail/news uses tree still, did you try that one?
I used bookmark sidebar, bookmark window, as well as folder stuff in mail news.

So things look good to me.

Put in my change from 36665 and see what you think.
invalids, wontfixes, dups, worksformes
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.