swaybar: scroll events are sometimes sent to swaybar even if it is hidden

[hhirtz]

Hi,

Sometimes, when the cursor is where swaybar should be when it's not hidden, scrolling changes the workspace (instead of moving the content of the focused window).

I think the required configuration should be:

• workspace_auto_back_and_forth is enabled
• bar.mode is set to hide
• the bar.modifier key is part of the bindsym to move between workspaces (bar.modifier is a subset of the move workspace x binding)

cf. at the end of the report for a configuration file that fulfill these requirements.

Example steps to reproduce (see debug log):

• open sway with the required config
• move to another workspace
• open a window (in the debug log alacritty is opened)
• move the cursor to where the bar is when it's shown
• don't move the cursor in the next steps
• move back to the previous workspace
• scroll down

Expected behavior: nothing happens Actual behavior: sway moves to the second workspace, the one with the window open

Sway Version: 1.4 Debug Log: https://gist.github.com/hhirtz/7bcfa30b72186943203cfe6044cb77b3#file-sway-log Configuration File: https://gist.github.com/hhirtz/7bcfa30b72186943203cfe6044cb77b3#file-config-txt

[ianyfan]

This is even easier to reproduce: just move the cursor where the bar would appear, press the modifier so that the bar shows briefly and then hides, then scroll.

[ianyfan]

So the issue seems to be more general: if the layer shells are arranged such that the surface under the pointer changes, i.e. a layer shell appears under the pointer or disappears from under the pointer, sway doesn't update the pointer focus. This does seem to be counter-intuitive, but I don't know what would be the sanest behaviour, and I'm not sure where the appropriate fix would be, maybe in arrange_layers?

[emersion]

Yeah, we should rebase the cursor when the layer surfaces layout changes. A more general solution would be to make layer shell use the atomic layout infrastructure.