| Commit-Queue | +1 |
This change makes sense to me. lgtm if the bots are happy.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
pinging thakis@
| Code-Review | +1 |
stamp
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Paint widgets as active based on xdg-shell activated state
According to xdg-shell, client window decorations should be painted as
active based on the `activated` state. From
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/911ab509edf6fc14b89599658199cc932417e9c8/stable/xdg-shell/xdg-shell.xml#L869-871
> Client window decorations should be painted as if the window is
> active. Do not assume this means that the window actually has
> keyboard or pointer focus.
Wayland separates the concepts of keyboard focus and paint activation,
but `OnActivationChanged` is used to signal both in Chromium. Since
https://crrev.com/c/6285685, `OnActivationChanged` has been driven by
keyboard focus when a keyboard is present. However, this causes the
window to be painted as inactive during move, resize, and compositor
window menu invocation.
Fix this by introducing `OnPaintAsActiveChanged`, which fires only on
Wayland. DesktopWindowTreeHostPlatform holds and releases a
paint-as-active lock in response to `OnPaintAsActiveChanged`. This
prevents crbug.com/365143359 from regressing while letting `activated`
state drive paint state.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |