can the browser indicate that it doesn't want the event? it will fall back to the parent (ash) which will latch? Seems like the easiest solution at the cost of 2 extra ipc on a mousedown or touchdown.

That's a cool idea. Looking at WindowManagerState::OnEventAck though, it doesn't seem like we have event bubbling in Mus implemented (yet?). Also, if we bubble to the parent ServerWindow, I don't think the event will be handled by WM - I think we would need to bubble it to the non-client area of the same window. So we'd need to add an extra step in the bubbling phase for unhandled events. But we can do this only for events that fall into additional_client_areas(), which probably wouldn't be too bad?

We wanted to avoid the extra hop when we know a particular client is going to handle it.

And Mikhai is certainly right that we don't handle bubbling correctly.

The client areas should support a more generic path, I went with rects as that was easiest at the time.

There's a probably a better way. vollick@ presented an issue with OOPIF event routing yesterday. The TL;DR is that an embedder needs a way to submit as part of its CompositorFrame additional regions for which events to it but the embedded child provides the actual pixels.

Seems like we could use the same mechanism: Ash submits "transparent occluders" over the region of the tabstrip that it wants the events for. But Chrome actually draws them.

I don't think we have a case here where Chrome needs to draw something but events should go to ash. Chrome draws the tabs and should get the events for the tabs. Ash draws the window frame including close/minimize/maximize buttons and should get the events for those. 

Related:  issue 613210 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is something which we still wish to pursue. However it will have to wait for the completion of the first major phase of the Viz project.

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

Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash