I suspect you are right. The windowmanager should only configure the hit region for windows that are resizable.

Did you mean the extended hit test region we use for resize handles on resizable windows?

If so, I don't think that's the issue. The events are definitely being sent to the window manager, starting ~32 pixels outside the bounds of the bubble. The extended hit test region is only 6 pixels.

The shadow in this case is ui/wm/core/shadow.cc, not mash/wm/shadow.cc, which is interesting. Also interesting is that the WS event dispatcher thinks these events are in the non-client region of the window, but that might just be because it doesn't hit the client area.

Is there some other place where hit test regions are set?

Yep, I meant the extended hit test region. As you say, that is only ~6 pixels. The shadow is definitely pretty large though, so we must some how be finding that in event testing. I recommend starting with EventDispatcher::PointerTargetForEvent and see where it goes wrong.

Yeah, I dug around in PointerTargetForEvent and I don't think it's doing anything special there.

The window server thinks the bounds of the bubble include the shadow region. That is, visually the white "window" part is 365 pixels tall, but the window server sees the window as 425 pixels tall (which presumably includes the shadows).

This bubble doesn't seem to create a WmNativeWidgetMus in the window manager, and doesn't have an extended hit region at all.

I think I'm wrong about who is drawing the shadow. msw@ mentioned that bubbles can make their own "shadows" with a custom set of border images, and I think that's what's going on here.

So the window really is 425 pixels tall. It has client-area insets of 31 pixels. I think the window server sends events to the window manager because it belives the events are in a non-client area for the window (since they aren't in the "contents" but still hit the window).

What I don't understand at this point is how the window server is getting the client area insets, but I can find that. More interesting is how the border skips clicks today in ash (via aura::WindowTargeter and a hit-test mask, it looks like) and how to adapt that to mash.

We might need to do something like reverse the "extended hit test" region to account for the visual border/shadows.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/265527f8745b9d36e277d7c93ed7818204baf323

commit 265527f8745b9d36e277d7c93ed7818204baf323
Author: jamescook <jamescook@chromium.org>
Date: Fri May 20 19:17:57 2016

mash: Preliminary support for widget hit test masks

This plumbs widget hit test masks through to the window server and uses them
for hit testing. It has the following limitations:
* Like "additional client areas" the mask is a rectangle, not a path.
* The mask is only updated on window bounds and client area change.

This fixes the system tray bubble not closing when you click in its bottom
border region, in particular the part that overlaps the tray button.

BUG= 612566 
TEST=added to mus_ws_unittests and views_mus_unittests

Review-Url: https://codereview.chromium.org/1991973003
Cr-Commit-Position: refs/heads/master@{#395133}

[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/cpp/lib/window.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/cpp/lib/window_tree_client_impl.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/cpp/lib/window_tree_client_impl.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/cpp/tests/test_window_tree.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/cpp/tests/test_window_tree.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/cpp/window.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/public/interfaces/window_tree.mojom
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/access_policy.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/default_access_policy.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/default_access_policy.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/event_dispatcher_unittest.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/server_window.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/server_window.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/window_finder.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/window_finder_unittest.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/window_manager_access_policy.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/window_manager_access_policy.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/window_tree.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/components/mus/ws/window_tree.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/ui/views/mus/native_widget_mus.cc
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/ui/views/mus/native_widget_mus.h
[modify] https://crrev.com/265527f8745b9d36e277d7c93ed7818204baf323/ui/views/mus/native_widget_mus_unittest.cc