+rjkroege@

To address the general proposal:) Send a copy of all low-frequency events (mouse up/down, keyboard) from
> mus-ws to ash, always.

I suspect the mouse up/down you mention includes touch up/down as well? I don't think we should do that (especially if we want to allow the wm to be able to consume the event). It will add latency to initiating a scroll, for example.

> B) EventWatcher.

I think what you have in mind is similar to EventObservers that we used to have. But instead of specific types of events, this would be for observing a class of events (e.g. 'all pointer events' instead of 'pointer up' events etc.)? As long as this is read-only, in the sense that the WM is not allowed to consume the event, this should be OK. I worry that we will be adding a lot of unnecessary IPC though.

> C) EventConsumer (needs a better name). Something that can listen to low-frequency
> events and optionally stop propagation.

The same issue applies as for (A) re up/down events.

To address the specific examples:

> 1. Laser pointer. Draws a red dot in a fullscreen transparent widget. Wants to
> consume all events... unless you tap on a button in the shelf, in which case
> it should fall through.

It's unclear to me what this is used for. But this should be doable with mus cleanly without needing any of the new API unless I am missing something?

Also, are we totally sure this laser code belongs in the window manager? We have traditionally put everything UI in ash/, but I was hoping we can start to move away from that with mus. If we continue that trend of putting all UI in the WM, then I think that would be pretty unfortunate. If possible, I would much rather the cros UI team starts to keep mus/mustash in mind, and try to decouple these things from ash as much as possible.

> 2. Status tray accessibility. Status tray is a bubble widget, not a menu,
> since it has complex non-menu behavior. The widget used to activate on
> open, but this caused ARC++ app windows to suspend, so the widget was
> changed to not activate. This breaks an a11y feature where escape and tab
> should close the widget, but not be consumed. This is easily fixed with
> an EventHandler.

Reviving the read-only EventObserver would solve this problem?

> 3. Shelf auto-hide. With material design there are no visible pixels
> when the shelf is hidden. Unless ash can listen for hover events we
> will have to add a special window server API to send a signal when
> the mouse is at the edge of the display and we can't reuse some of
> the existing code (which also handles things like bezel gestures).

I actually think proximity events would be a good idea. I believe chromevox UI also will need similar functionality.

> Right now engineers building features like these end up delegating
> functionality out of //ash/common back into //ash so they can use
> EventHandler, which makes more work for mustash down the road.

I haven't run into issues myself since I am not closely involved with the work in ash, but I feel like the issues that crop up can be fixed using some better suited API than pre/post target handlers that are way too powerful, and can very easily (and unexpectedly) affect the entire system. I would like to avoid having this in the API.

One of the places I've encountered that requires the wm and chrome to see and potentially consume events before they go through the normal flow is immersive mode. See ImmersiveFullscreenController::OnGestureEvent(). I can't see a good way to accomplish this without some sort of pre handler that sees all events.

In thinking through the laser pointer case I *think* it can be handled with a fullscreen window placed on top of everything that normally consumes everything, but doesn't for the buttons it wants to allow clicks on.

By "Send a copy of all low-frequency events to ash" I meant a read-only copy, not to wait for a round trip.

Something like EventWatcher/EventObserver would help. I don't think we should bother building a configurable watcher/observer mechanism into the window server. I would just hard code a list of the event types we think are interesting for a window manager and low frequency enough. Later we could try to reduce the IPC traffic as an optimization (maybe we don't need all key events all the time), but I would like to start simple.

I can provide more details on the laser feature via email.

Deprecating label Proj-Mustash-Mus-WS in favor of Components.

Now that ash hosts the ws, this isn't an issue. I'm going with fixed, as since ash is hosting the ws it sees all events, which is what this bug wanted.

Should we eliminate PointerWatcher inside of ash and revert the code that uses it back to EventHandler?

https://cs.chromium.org/search/?q=f:src/ash+-f:src/ash/components+public.*PointerWatcher&sq=package:chromium&type=cs

Yes, there is no reason to use PointerWatcher in ash now.