Horizontal scrolling is backwards in imgui_impl_win32 and imgui_impl_sdl

[PathogenDavid]

Version/Branch of Dear ImGui:

Version: current master, current docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_win32.cpp + imgui_impl_dx11.cpp
Back-ends: imgui_impl_sdl.cpp + imgui_impl_dx11.cpp
Compiler: MSVC 19.28.29913 x64 (Visual Studio 2019 16.9.3)
Operating System: Windows 10 x64 20H2 (19042.867)

My Issue/Question:

The horizontal scrolling direction in Dear ImGui with the Win32/SDL backends is backwards when compared to other Windows applications. It is correct with the imgui_impl_glfw backend. This issue is observable in the official examples. (I specifically tested example_glfw_opengl3, example_sdl_directx11, and example_win32_directx12.)

For the sake of clarity, I am going to describe scrolling in terms of what the scrollbar's grabber does in response to you moving the mouse wheel.

1. Launch something with horizontal scrolling that isn't powered by Dear ImGui. (IE: Visual Studio, a web browser.)
   a. Open content which is too wide for the screen or resize the window so a horizontal scrollbar appears.
   b. Press right on the scroll wheel. The grabber moves to the right.
   c. Press left on the scroll wheel. The grabber moves to the left.
2. Launch example_win32_directx12
   a. In the demo window, expand Layout & Scrolling and then Scrolling b. Uncheck Track`
   c. In one of the horizontal scrolling examples...
   d. Press right on the scroll wheel. The grabber moves to the left.
   e. Press left on the scroll wheel. The grabber moves to the right.
3. Repeat step 2 with example_sdl_directx11, same result.
4. Repeat step 2 with example_glfw_opengl3:
   a. When pressing right on the scroll wheel, The grabber moves to the right.
   b. When pressing left on the scroll wheel, The grabber moves to the left.

As you can see, example_win32_directx12/example_sdl_directx11 are backwards from what would be expected when compared to other Windows apps as well as example_glfw_opengl3.

Screenshots/Video

This issue is difficult to convey in screenshots/video. I believe it should be apparent from following the steps above.

Standalone, minimal, complete and verifiable example:

This issue reproduces in the Dear ImGui examples without changes.

---

Root cause

This issue essentially happens because Dear ImGui treats MouseWheelH in the positive as being a scroll to the left. (Which mirrors positive MouseWheel being a scroll up.)

However, both WM_MOUSEHWHEEL and SDL_MouseWheelEvent.y are defined as positive being a scroll to the right. (GLFWscrollfun does not say, but it's apparently the opposite. Probably to make it consistent with yoffset which is positive up for all three.)

Proposed fix

The easiest fix would be to document the expectation for both ImGuiIO::MouseWheel and ImGuiIO::MouseWheelH, and flip them in the affected backends.

Additionally, the horizontal scrolling in ImGui::UpdateMouseWheel could also be flipped to match the convention of SDL/Windows. If this is done, I think it needs to be done by flipping the MouseWheelH read rather than flipping the call to SetScrollX as the latter would affect shift scrollings. (In my opinion, the current shift scrolling is intuitive. There's not a lot of precedent for this interaction on Windows, but Photoshop and Dear ImGui both move the grabber left if I use control/shift+scroll up.)

The downside of modifying ImGui::UpdateMouseWheel is that it could potentially break custom backends. Although since the direction of MouseWheelH wasn't defined before, it's possible this bug is present in many custom backends as well. (I actually originally discovered this issue in my own custom backend since I expected positive right.)

[ocornut]

Thank you David!
Will investigate this later. For now linking to #3394 and #1463
Note that #3394 didn't investigate SDL and didn't connect that MouseWheelH value to Scrolling.

[PathogenDavid]

Ah, I bet #3394 was the same issue but they blamed the wrong thing. The ALLEGRO_EVENT_MOUSE_AXES documentation doesn't explicitly say, but based on the description of mouse.z I'd assume mouse.w is positive right like SDL and Windows. Odd that they said SDL was correct for them though, that makes me wonder if SDL has a bug on Linux that cancels this out there.

Also this reminded me I meant to check on my laptop too for the sake of sanity. I can confirm its trackpad acts the same as my desktop's mouse. (GLFW matches other apps, Win32 and SDL are backwards.)

[rokups]

Can confirm that inverting x axis on SDL/Win32 works as expected. This also works properly on MacOS when holding SHIFT (92b7b1f caused some problems regarding that). While testing this i noticed that for some reason wheel acceleration was disabled. Allowing SDL to accelerate wheel does not seem to have any unwanted effects and makes wheel behave consistently in imgui and native applications, so i included that change in commit linked above as well.

[ocornut]

@rokups I believe "wheel acceleration" should be left to a separate discussion and PR, it's probably not a simple topic to handle as the amount are not well defined across platforms/backends. It'd be useful to report how those mouse wheel values are generated by SDL for every platform.

It's difficult to test a way to natively send MOUSEWHEELH events here, and Mac mouse drivers on drivers have options to invert the axis making things more confusing. Additionally I'm unsure all OS scroll the same way depending on mouse.

Odd that they said SDL was correct for them though, that makes me wonder if SDL has a bug on Linux that cancels this out there.

That should be enough of a hint to suggest we might be overlooking something. I think we need a wider range of tests done across platforms (+ bonus checking if third-party drivers involved have invert options). That person basically says SDL and GLFW works the same for them, and now we are inverting SDL but not GLFW. We are missing something.

SHIFT+vertical wheel also needs testing separately from horizontal wheel.

[rokups]

I split wheel acceleration to separate commit. I also verified behavior on all three OS.

Windows: does not have a concept of wheel acceleration. Modifying wheel speed in OS settings has no effect on scrolling speed, event always returns +1/-1. End result: no change compared to current behavior.
Linux (X11/KDE): does not have a concept of wheel acceleration or wheel scroll speed. End result: no change compared to current behavior.
MacOS: does have wheel acceleration and wheel scroll speed can be changed in OS settings. SDL does react to OS settings. End result: these changes make imgui scrolling consistent with other MacOS applications. Without these changes wheel is as useless as on windows/linux when trying to navigate big scroll areas.

tl;dr; acceleration change only improves usability on MacOS and changes nothing on windows (SDL bug?) and linux (lacking desktop environment).

Edit: Forgot to mention SHIFT+vertical. Currently this is broken on MacOS, because we delegate axis swapping to OS function. Inverting MouseWheelH fixes SHIFT+vertical scroll. Change has no effect on SHIFT+vertical on other OS because we ourselves use vertical axis for horizontal scroll, and vertical axis is working properly already.

[rokups]

OS is configured so scrollbar moves to the direction of wheel (which means on MacOS natural scrolling is disabled).

Linux (SDL2)
Modifiers do not change wheel direction.
Amplitude can reach -10/+10 or more on rapid flicks.
Up           = +1 +0
Down         = -1 +0
Left         = +0 +1   // Incorrect, fix pending https://github.com/libsdl-org/SDL/pull/4700
Right        = +0 -1   //


Linux (GLFW)
Modifiers do not change wheel direction.
Amplitude can reach -10/+10 or more on rapid flicks.
Up           =    +1    +0
Down         =    -1    +0
Left         =    +0    +1
Right        =    +0    -1

Windows (SDL2)
Modifiers do not change wheel direction.
Amplitude can reach -2/+2, but flicks produce continuous event stream, simulating a wheel that is spinning when released.
Up           =    -1    +0
Down         =    -1    +0
Left         =    +0    -1
Right        =    +0    +1

Windows (GLFW)
Modifiers do not change wheel direction.
Amplitude can reach -1/+1, API may report -1 < value < 1 due to values divided by `WHEEL_DELTA`.
Up           =    +1    +0
Down         =    -1    +0
Left         =    +0    +1
Right        =    +0    -1

Windows (Win32)
Modifiers do not change wheel direction.
Amplitude can reach -1/+1, API may report -1 < value < 1 due to values divided by `WHEEL_DELTA`.
Up           =    +1    +0
Down         =    -1    +0
Left         =    +0    -1
Right        =    +0    +1

MacOS (SDL2)
Amplitude can reach -12/+12 or more on rapid flicks. Values are always whole numbers.
Up           =    +1    +0
Down         =    -1    +0
Up   + Shift =    +0    -1  // Only available with a mouse, not working on a touchpad
Down + Shift =    +0    +1  //
Left         =    +0    -1
Right        =    +0    +1

MacOS (GLFW, mouse)
Amplitude can reach -6/+6 or more on rapid flicks.
Values can be fractional, single wheel tick is 0.1.
Up           =    +1    +0
Down         =    -1    +0
Up   + Shift =    +0    +1  // Only available with a mouse, not working on a touchpad
Down + Shift =    +0    -1  //
Left         =    +0    +1
Right        =    +0    -1

We are dealing with three distrinct bugs.

1. Inverted scrolling in Win32 backend.
2. Inverted scrolling in SDL backend.
3. SDL2 reports inverted horizontal scroll on X11/Linux.

As a result we get:

• Horizontal scroll is inverted on windows with win32 and sdl backends due to bugs in our backends.
• Horizontal scroll is inverted on MacOS with sdl backend due to bug in sdl backend.
• Horizontal scroll works as expected on X11/Linux with sdl backend due to double inversion caused by bugs in sdl backend and sdl itself.

I submitted a PR to SDL to fix inverted events in X11 backend: libsdl-org/SDL#4700.
While proposed fix is correct, it could include a workaround for SDL on Linux, taking into account inverted events on SDL versions before my proposed fix is merged. So now we wait for SDL people to take care of that PR.

[ocornut]

Ignore the table/data here and refer to XLS file in subsequent post.

Extra data (will add more as I test on my PC laptop with a touchpad)

Someone recently wondered why the SDL backend clamping mouse wheel inputs to -1/+1 (thread #6081) I didn't have a good answer yet as this clamping was added many years ago.

Interestingly, I tested the SDL2+Emscripten example and confirmed odd findings, namely that the scale of wheel values reported on Emscripten vary depending on the browser. I also tested GLFW+Emscripten and got same values.
From the values I am getting, I don't think the / 20.0f is any correct :(
(You can visualize the values in Demo->Tools->Debug Log->IO)

Misc

• SDL backend had wheel clamping removed.
• The GLFW backend doesn't clamp the wheel value.
• Couldn't test horizontal on all computers yet.
• The web/Emscripten runs are for the same build (hosted by the same Windows machine).
• Couldn't get to run on OSX+Firefox (website shows black) so tested only Safari and Chrome there.

I also noticed SDL 2.0.18 added "preciseX/preciseY" fields so I am also testing those, but they are not available in Emscripten latest.

typedef struct SDL_MouseWheelEvent
{
    Sint32 x;           /**< The amount scrolled horizontally, positive to the right and negative to the left */
    Sint32 y;           /**< The amount scrolled vertically, positive away from the user and negative toward the user */
    Uint32 direction;   /**< Set to one of the SDL_MOUSEWHEEL_* defines. When FLIPPED the values in X and Y will be opposite. Multiply by -1 to change them back */
    float preciseX;     /**< The amount scrolled horizontally, positive to the right and negative to the left, with float precision (added in 2.0.18) */
    float preciseY;     /**< The amount scrolled vertically, positive away from the user and negative toward the user, with float precision (added in 2.0.18) */

**From Windows 11, Desktop 1**

Mouse Wheel Values:

- Mouse - Native+(GLFW,SDL,Win32):       UP: +1   / DOWN: -1   (occasionally a little more +2,+3 etc.) (SDL's precise fields are same)
- Mouse - Firefox+Em+(SDL,GLFW)          UP: +108 / DOWN: -108 (fixed steps)
- Mouse - Chrome+Em+(SDL,GLFW):          UP: +350 / DOWN: -350 (fixed steps)
- Mouse - Edge+Em+(SDL,GLFW):            UP: +175 / DOWN: -175 (fixed steps)
- Can't test horizontal wheel ont his machine.
- On none of the 6 config above (3 native, 3 browse) Shift has an effect turning WheelY into WheelX.

**From Windows 11, Laptop 2"

Scrolling behavior:

- VS: Mouse       DOWN scrolls DOWN
- VS: Mouse    B4+DOWN scrolls RIGHT
- PS: Mouse  CTRL+DOWN scrolls RIGHT
- VS: Touch       DOWN scrolls UP           With "Down motion scrolls up"   in Settings->Touchpad
- VS: Touch       LEFT scrolls RIGHT        With "Down motion scrolls up"   in Settings->Touchpad
- VS: Touch       DOWN scrolls DOWN         With "Down motion scrolls down" in Settings->Touchpad
- VS: Touch       LEFT scrolls LEFT         With "Down motion scrolls down" in Settings->Touchpad

- Win32: Mouse    DOWN scrolls DOWN
- Win32: Mouse B4+DOWN scrolls LEFT *KO*
- Win32: Touch    DOWN scrolls UP          With "Down motion scrolls up"   in Settings->Touchpad
- Win32: Touch    LEFT scrolls LEFT *KO*   With "Down motion scrolls up"   in Settings->Touchpad

- SDL:   Mouse    DOWN scrolls DOWN
- SDL:   Mouse B4+DOWN scrolls LEFT *KO*
- SDL:   Touch    DOWN scrolls UP          With "Down motion scrolls up"   in Settings->Touchpad
- SDL:   Touch    LEFT scrolls LEFT *KO*   With "Down motion scrolls up"   in Settings->Touchpad

- GLFW:  Mouse    DOWN scrolls DOWN
- GLFW:  Mouse B4+DOWN scrolls RIGHT
- GLFW:  Touch    DOWN scrolls UP          With "Down motion scrolls up"   in Settings->Touchpad
- GLFW:  Touch    LEFT scrolls RIGHT       With "Down motion scrolls up"   in Settings->Touchpad

Mouse Wheel Values:

- Mouse    - Native+(GLFW,SDL,Win32)     UP: y +1      /    DOWN: y -1
- Mouse    - Native+(SDL,Win32)       B4+UP: x -1      / B4+DOWN: x +1
- Mouse    - Native+(GLFW)            B4+UP: x +1      / B4+DOWN: x -1
- Touchpad - Native+(GLFW,SDL,Win32)     UP: y -1~     /    DOWN: y +1~  (smoothed, bigger inertia than mac)    UP   scrolls down  in VS, DOWN  scrolls up i  n VS
- Touchpad - Native+(SDL,Win32)        LEFT: x +1~     /   RIGHT: x -1~  (smoothed, bigger inertia than mac)   LEFT  scrolls right in VS, RIGHT scrolls LEFT in VS
- Touchpad - Native+(GLFW)             LEFT: x -1~     /   RIGHT: x +1~  (smoothed, bigger inertia than mac)

- Mouse    - Firefox Em-Raw              UP: y -108     /    DOWN: y +108
- Mouse    - Firefox Em-Raw           B4+UP: x -36      / B4+DOWN: x +36
- Touchpad - Firefox Em-Raw              UP: y +1~30  /    DOWN: y -1~-30  (smoothed, bigger inertia than mac)   UP   scrolls down  in VS, DOWN  scrolls up i  n VS
- Touchpad - Firefox Em-Raw            LEFT: x +1~30  /   RIGHT: x -1~-30  (smoothed, bigger inertia than mac)   UP   scrolls down  in VS, DOWN  scrolls up i  n VS

- Mouse    - Edge Em-Raw                 UP: y -125     /    DOWN: y +125
- Mouse    - Edge Em-Raw              B4+UP: x -125     / B4+DOWN: x +125
- Touchpad - Edge Em-Raw                 UP: y +1~150   /    DOWN: y -1~-150  (smoothed, bigger inertia than mac)
- Touchpad - Edge Em-Raw               LEFT: x +1~150   /   RIGHT: x -1~-150   (smoothed, bigger inertia than mac)

- Mouse    - Firefox Em-SDL             n/a
- Mouse    - Firefox Em-SDL             n/a
- Touchpad - Firefox Em-SDL             n/a
- Touchpad - Firefox Em-SDL             n/a

- Mouse    - Edge Em-SDL                 UP: y +125     /    DOWN: y -125
- Mouse    - Edge Em-SDL              B4+UP: x -125     / B4+DOWN: x +125
- Touchpad - Edge Em-SDL                 UP: y -1~-150  /    DOWN: y +1~+150  (smoothed, bigger inertia than mac)
- Touchpad - Edge Em-SDL               LEFT: x +1~+150  /   RIGHT: x -1~-150  (smoothed, bigger inertia than mac)

**From OSX: Vertical Wheel**

- 3rdparty Mouse - Native SDL:           UP: -1.0 to -~30   /    DOWN: +1.0 to +~30   (depends on wheeling velocity) (precise fields are same)
- 3rdparty Mouse - Native GLFW:          UP: -0.1 to -~30   /    DOWN: +0.1 to +~30   (depends on wheeling velocity).
- 3rdparty Mouse - Safari SDL:           UP: -4   to -~600  /    DOWN: +4   to +~600  (depends on wheeling velocity).
- 3rdparty Mouse - Safari GLFW:          UP: +4   to +~600  /    DOWN: -4   to -~600  (depends on wheeling velocity).
- 3rdparty Mouse - Chrome SDL:           UP: -8   to -~1200 /    DOWN: +8   to +~1200 (depends on wheeling velocity).
- 3rdparty Mouse - Chrome GLFW:          UP: +8   to +~1200 /    DOWN: -8   to -~1200 (depends on wheeling velocity).
- 3rdparty Mouse - Firefox SDL:          n/a
- 3rdparty Mouse - Firefox GLFW:         UP: +16  to +~800  /    DOWN: -16  to -~800  (depends on wheeling velocity).

- 3rdparty Mouse - Native SDL:        Sh+UP:  1.0 to +~30   / Sh+DOWN: -1.0 to +~30   (with SHIFT. all values becomes rounded) (precise fields are same)
- 3rdparty Mouse - Native GLFW:       Sh+UP: -1   to -~30   / Sh+DOWN: +1   to +~30   (with SHIFT. all values becomes rounded)
- 3rdparty Mouse - Safari SDL:        Sh+UP: +40  to +~600  / Sh+DOWN: -40  to -~600  (depends on wheeling velocity).
- 3rdparty Mouse - Safari GLFW:       Sh+UP: +40  to +~600  / Sh+DOWN: -40  to -~600  (depends on wheeling velocity).
- 3rdparty Mouse - Chrome SDL:        Sh+UP: +80  to +~1200 / Sh+DOWN: -80  to -~1200 (depends on wheeling velocity).
- 3rdparty Mouse - Chrome GLFW:       Sh+UP: +80  to +~1200 / Sh+DOWN: -80  to -~1200 (depends on wheeling velocity).
- 3rdparty Mouse - Firefox SDL:       n/a
- 3rdparty Mouse - Firefox GLFW:      Sh+UP: +9   to +~200  / Sh+DOWN: -9   to -~200  (depends on wheeling velocity).

**From OSX: Touchpad Swipe**

- Laptop Touchpad - Native SDL:          UP: -1.0 to -~30   /    DOWN: +1.0 to +~30   (little/no smoothed inertia) (precise fields are more precise but lack of smoothing is strange)
- Laptop Touchpad - Native GLFW:         UP: -0.1 to -~20   /    DOWN: +0.1 to +~20   (with smoothed inertia).
- Laptop Touchpad - Safari SDL:          UP: -1   to -~30   /    DOWN: +1   to +~30   (with smoothed inertia).
- Laptop Touchpad - Safari GLFW:         UP: +1   to -~30   /    DOWN: -1   to -~30   (with smoothed inertia).
- Laptop Touchpad - Chrome SDL:          UP: -2   to -~300  /    DOWN: +2   to +~300  (with smoothed inertia).
- Laptop Touchpad - Chrome GLFW:         UP: +2   to -~300  /    DOWN: -2   to +~300  (with smoothed inertia).
- Laptop Touchpad - Firefox SDL:         n/a
- Laptop Touchpad - Firefox GLFW:        UP: +1   to -~30   /    DOWN: -1   to -~300  (with smoothed inertia).

**From OSX: Touchpad Swipe (Horizontal)**

- Laptop Touchpad - Native SDL:        LEFT: +1.0 to +~30   /   RIGHT: -1.0 to -~30   (little/no smoothed inertia).
- Laptop Touchpad - Native GLFW:       LEFT: -0.1 to +~20   /   RIGHT: +1.0 to +~30   (with smoothed inertia).
- Laptop Touchpad - Safari SDL:        LEFT: +1.0 to +30    /   RIGHT: -1.0 to -~30   (with smoothed inertia).
- Laptop Touchpad - Safari GLFW:       LEFT: +1.0 to +30    /   RIGHT: -1.0 to -~30   (with smoothed inertia).
- Laptop Touchpad - Chrome SDL:        LEFT: +2.0 to +300   /   RIGHT: -2.0 to -~300  (with smoothed inertia).
- Laptop Touchpad - Chrome GLFW:       LEFT: +2.0 to +300   /   RIGHT: -2.0 to -~300  (with smoothed inertia).
- Laptop Touchpad - Firefox SDL:       n/a
- Laptop Touchpad - Firefox GLFW       LEFT: +1.0 to +200   /   RIGHT: -1.0 to -~200  (with smoothed inertia).

*EDITED 4 times. added glfw+emscripten, added windows info with mouse that has horizontal inputs + with touchpad.

[topolarity]

Are these data the raw value per event, or are they accumulated over a period of time?

I've seen that slow scrolls become heavily batched/under-sampled on some systems (e.g. Native macOS), so it's probably necessary to accumulate for an apples-to-apples comparison.

[ocornut]

Are these data the raw value per event,

Per event.
(There is an accumulation done in our scrolling code for sub-pixel values.)

Notes:

• We should decide what sign should be a LEFT wheel/swipe and RIGHT wheel/swipe BEFORE deciding on a scroll direction.
• Then we make backends and platform consistent.
• We should confirm if SHIFT+UP always means same sign as LEFT (table above suggests so).

About GLFW:

• GLFW+Emscripten (*) somehow report wheel values opposite of SDL+Emscripten for Y axis.
• GLFW Horizontal Sign is indeed inconsistent between Native and Emscripten.
  (*) built from a Windows machine, haven't tested building FROM OSX but I think would make no difference. But I'll double-check.

Note opening thread message:

The horizontal scrolling direction in Dear ImGui with the Win32/SDL backends is backwards when compared to other Windows applications. It is correct with the imgui_impl_glfw backend. This issue is observable in the official examples. (I specifically tested example_glfw_opengl3, example_sdl_directx11, and example_win32_directx12.)

A per the scary table above, further notes:

• I think wheel up and swipe up should be standardized as positive values (and down as negative values) based on typical Windows machine behavior.
• Which means all backends should flip Y on OSX (undo natural scrolling setting), and core imgui does opposite flip in scrolling code (based on runtime boolean set based on natural scrolling setting) ? So when using a wheel to scroll on OSX, values are flipped twice, but this ensure the values in MouseWheel are consistent across platforms and backends.
• We expose a runtime value specifying the sign of scroll up and the sign of scroll down, which widgets (e.g. one performing Scrolling) can use.

Question:

• Can someone using Unity or Unreal with access to both PC or Mac can confirm if there are widgets where you can edit e.g. an int or float with mouse wheel, and if the direction of change is swapped based on natural scrolling setting, aka if non-scrolling types of inputs relying on mouse wheel are also affected by the flip ?
• How about Zooming behavior?

[ocornut]

FYI there's no action needed; other than the two questions above (for people who can run Unity or Unreal on two platforms).

I've gathered good data and will add more soon and then attempt some fixes for the horizontal direction issues.

[topolarity]

Per event.
(There is an accumulation done in our scrolling code for sub-pixel values.)

Is it possible then that the event rates are different, in addition to the event scaling?

I'll dive in soon and try to reproduce some of your findings, or at least make sure these match my previous measurements

[ocornut]

I have pushed 3617a96 fixing most issues discussed here.

Remaining issues IHMO:

• The magnitude of wheel inputs under Emscripten (with SDL or GLFW backends) is still a problem which I have merely used a dumb scale factor for. We should continue this specific discussion in Emscripten mouse wheeling (was: GLFW Emscripten fixes) #6096.
• When running on Emscripten under OSX, Shift+WheelY with a mouse will be cancelled by our own handling of Shift+WheelY, this is because io.ConfigMacOSXBehaviors is not set. We should either disable Shift+WheelY support turning into WheelX on Emscripten, or find a way to detect an OSX client under OSX.

Attached my data reworked and converted to an Excel sheet. Please ignore table posted a few posts above as this sheet is more complete and more accurate.
You can see the 4 fixes that have been done and why.

Wheeling Notes 2023-02-01.xlsx

Thank you !

[ocornut]

Duh i also accidentally pushed a WIP example for GLFW+Emscripten which i didn’t intend to include in that commit (reason: somehow git stashes don’t stash new files unless staged). So expect that to be removed or massaged later, perhaps folded into existing examples.

[PathogenDavid]

git stashes don’t stash new files unless staged

You can use --include-untracked/-u with git stash save/push to include them. (I also hate the default behavior.)