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()

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.

This doesn't seem to be a problem anymore.

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