As far as I can tell, clicking on the drop shadow of our current Windows context menus does not close them. That's fine for those because the drop shadow is approximately 1 pixel, but for the Proton design the shadow is a much larger target, so we should have clicks in that region close the popup.

This is a bit worse than just clicks - if you're opening a submenu and those are correctly aligned (ie after fixing bug 1692081), the menu underneath also doesn't get hover effects, so there's a 30px dead zone that doesn't do anything...

I haven't been able to get very far with this. I finally found where to insert the right hooks to make us return HTTRANSPARENT from the WM_NCHITTEST handler for a region of the popup, and verified in the debugger that we are in fact doing that, but then that region just gets regular mouse messages in the same window as if nothing had happened. I have no idea why.

Gijs also found that, while HTTRANSPARENT seems to have no effect at all, WS_EX_TRANSPARENT set on the popup does take effect, but only partially; specifically, mouse events that occur on portions of the popup that do not overlap the parent window (such as when a context menu is opened near the edge of a nonmaximized browser window so that it partially hangs off the side) are not received. Mouse messages that occur on the portion of the popup which does overlap the parent window seem to get handled, but the window messages are being received by the parent window, not by the popup. So, it appears something is relaying the events from the parent up to the popup, but whatever it is doesn't seem to be in the form of Win32 messages, so I'm not sure where it's happening.

Neil, do you have any pointers that might help lead us to what's going on there?

(In reply to Molly Howell (she/her) [:mhowell] from comment #3)

Gijs also found that, while HTTRANSPARENT seems to have no effect at all, WS_EX_TRANSPARENT set on the popup does take effect

To be clear (and sorry for the confusion around this), I tried applying both the HTTRANSPARENT return value for the NCHITTEST message and applying the transparent extended style and then noticed the effect Molly described in the rest of her comment. I don't know which of these 2 changes is necessary/sufficient to cause this to happen and I literally just shut down my Windows machine for the night... (but perhaps you tested this as well, Molly?)

I tried both; HTTRANSPARENT has no effect whatsoever for me, with or without WS_EX_TRANSPARENT.

So, to clarify, with the test you did using WS_EX_TRANSPARENT, the mouse events are fine when the popup is over a different application window?

What about when over another Firefox window that the popup doesn't belong to?

For events on a popup over a window, it is likely just hit-testing. This is done by nsLayoutUtils::GetFrameForPoint. Since the popup and the window is belongs to are the same document, it should redirect to the popup as needed. This could just be a case where nsMenuPopupFrame just needs to implement BuildDisplayListForChildren and return early when the coordinate is within the padding-area. There might even be something in the display list stuff that does these kind of things.

That said, it's been a while since I did anything with display lists, they may work differently now, and I'm not sure how it would work with different processes weh ave now, so I would ask a layout/graphics person(someone like mstange or tnikkel) about it for more specifics.

Actually, since all we care about is when the click is in the dropshadow area where the popup should close, modifying nsWindow::EventIsInsideWindow to inset the rectangle by the padding size should allow the popup to hide when clicking in the dropshadow area. I don't think that will handle passing the click to whatever is behind the popup though.

(In reply to Neil Deakin from comment #6)

So, to clarify, with the test you did using WS_EX_TRANSPARENT, the mouse events are fine when the popup is over a different application window?

Over a different application window (or just the desktop window), the mouse transparency takes effect as expected and events don't arrive. Over the parent Firefox window, events appear to get handled as if there were no transparency.

What about when over another Firefox window that the popup doesn't belong to?

I hadn't thought to try that before, but I just did and I don't see any change in the behavior vs. the underlying window being a different application or the desktop; the popup over the other Firefox window is transparent to the mouse.

(In reply to Neil Deakin from comment #7)

Actually, since all we care about is when the click is in the dropshadow area where the popup should close, modifying nsWindow::EventIsInsideWindow to inset the rectangle by the padding size should allow the popup to hide when clicking in the dropshadow area. I don't think that will handle passing the click to whatever is behind the popup though.

It looks like you were right about this; I tried shrinking the window rect in EventIsInsideWindow and it does get the popup closed, but does not pass the click through to what's under it.

Marking as P1. Per experience review we agreed to mark as P1 bug the ones that will block MR1.

This is now fixed by bug 1699427.