Actually, it cannot be dismissed at all. This makes it hard to work on.
This happens even if the painting problem (it's blank) is worked around.
Perhaps something is wrong with event routing or capture. I'll take a look.
The inability to capture events outside the bubble area is likely related.
For example, with tooltips, we add a pre target handler to the root aura window to capture touch events outside the shelf, but that doesn't work on our current mus setup, because the root window is the size of the shelf, not the entire desktop, and you can't easily hook events outside your mus window. I wonder if that bubble works similarly; TrayBubbleView always worked a bit differently from other bubbles (which I know much better).
Forcing TrayBubbleView's can_activate to true might make close_on_deactivate work.
You could also try BubbleDelegateView::set_close_on_esc(true), at least for testing.
https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/bubble/tray_bubble_view.cc&l=282
The system tray bubble does not use mouse capture to decide when to close. It has custom close behavior created by TrayEventFilter, which is installed on the ash::Shell as-a EventTarget.
The TrayEventFilter has custom logic for behaviors like not closing the tray on click if there is a notification window open above it (since that would shift the position of the notification window):
https://code.google.com/p/chromium/codesearch#chromium/src/ash/system/tray/tray_event_filter.cc
In mustash the Shell EventFilter is created, but doesn't seem to get any events. This might happen because of the existing event routing architecture.
Talked to Sadrul....
Events go directly from the mus window server into the mus::WindowTreeClientImpl into NativeWidgetMus and from there into views::Widget. It bypasses the aura-window/ash-shell event processing layer.
Basically, there's no way to do a global pre-target handler like the existing event filters in Ash. The window server doesn't want to talk to each running mojo app and ask it if it wants to handle an event -- that's too slow. Mouse events either go to the window under the cursor or the window capturing the mouse.
Right now there are ~10 pre-target handlers registered in ash::Shell. None of these are going to work, and we need to find workarounds.
In this case it might be OK to have the tray bubble capture the mouse, similar to how context menus work. This won't be exactly right, as the event filter is doing some interesting stuff with popup notifications, but it could be close. This will need to be refactored so that the existing Chrome OS Ash behavior is preserved, but we can do the new thing under mus.
Sadrul, do you know if mouse capture in Mus also gives you touch capture?
msw@, did you find a way to simulate touch events when running on your Linux desktop?
Mus does implicit capture on a per-pointer basis (separate for mouse/touch)
Mus' explicit capture covers all mouse+touch. This is what menus use for self-dismissal.
For other pre-target handlers Mus supports pre-target accelerators. We may be able to map some of those over.
In addition to the TrayEventFilter discussed above, there is another way the bubble closes itself. The bubble is a widget that listens for itself to be deactivated. When that happens it closes. You can see this behavior on a Chromebook by opening a browser window, opening the system tray bubble, then hitting alt-tab. When the browser window activates itself the bubble loses activation and closes.
This is broken for several reasons: NativeWidgetMus::drawn_ is never true (sky is working on this), NativeWidgetMus isn't notifying the Widget of activation change, and the bubble is in the MENUS container, which doesn't allow activation.
I'm close to having a patch for the latter 2 issues, which will fix the deactivation case. However, this doesn't fix the common case of closing the bubble via clicking on the desktop.
The TrayEventFilter/EventHandler case will need to be fixed with something like mouse capture, as described above.
I'm going to try a different approach that may help us in the future with EventHandlers/EventFilters/MouseWatchers.
ash_sysui will register itself with the window server as an "EventObserver". It will get a stream of input events that it can passively observe. The WS will not expect ACKs on those events, it's a one-way stream. This won't add latency to normal events; they will be delivered as they are now.
The tray bubble will register a "PointerWatcher" on its WindowTreeConnection. It will get notified of pointer-down events and use them to decide when to close the bubble. This is similar to how TrayEventFilter works today.
Comment 1 by msw@chromium.org
, Mar 30 2016