layout/scrolling: fix viewport bug when moving window to another workspace

[erstarr]

Describe your PR, what does it fix/add?

• Misc. Refactoring:

  • Rename some focus reasons to be more accurate
  • Move some focus reasons around to group them logically
  • create another focus reason other than the one needed for the bugfix below so users can distinguish a non-silent workspace move from a silent one from window.active. This one, used when moving a window to a workspace non-silently.

• Fix a bug with unwanted viewport move when moving a floating window to another workspace

Repo steps:

window: colresize 0.5 | window: colresize 0.8

Move viewport to 0.5 window so that the 0.8 window is partially off the screen

Create a floating window (spawn float or create then restore above config). establish focus history so that when this floating window is sent to another workspace, focus falls back to the 0.8 window

Move the floating window to another workspace with follow=false (special or not). Viewport moves to make 0.8 window fully in view.

This MR fixes that

Also, more focus reasons is good for window.active too and allows for better lua scripting

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Attempt to create a test: fails inexplicably.

Details

I tried to make tests for this fix. I created 2; same exact code except one has follow_focus = false and one = true.

The = true passes perfectly, but =false fails because focus fallback does not work for reasons unknown. There are numerous other tests, 2 in scrolling, with focus fallback configured exactly like = false test (code exactly the same) yet they all pass.

I investigated the codepath also, all places where follow_focus config value is used; the passing scroll test (kill floating window, focus fallback) should fail in the same way if that was the reason but it doesn't.

Other than the test stubbornly failing, everything else if fine. Hyprtester's focus behaviour has been fickle in some tests I wrote before.

Is it ready for merging, or does it need work?

Ready

I'll investigate the test failing when I have spare time, but the bugfix for this bug will in any case be the same so this can be merged first

[github-actions]

Hello and thank you for making a PR to Hyprland!

Please check the PR Guidelines and make sure your PR follows them.
It will make the entire review process faster. :)

If your code can be tested, please always add tests. See more here.

beep boop, I'm just a bot. A real human will review your PR soon.

[vaxerski]

where test

[erstarr]

Attempt to create a test: fails inexplicably.

problem with its creation: noted in desc.

I'll investigate the test failing when I have spare time, but the bugfix for this bug will in any case be the same so this can be merged first

It can wait until that's resolved if the test is non negotiable

[vaxerski]

pretty much non negotiable for new features / fixes that can be tested. I don't want shit I dont use randomly breaking because I didnt test them

[erstarr]

Ok converting to draft for now until I find time to figure out why focus fallback is no worky