Wandering dropdown menu

[Artaga734]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

When opening a dropdown menu to choose from the options, if the dropdown is too long and cannot entirely be seen, moving the mouse and scrolling sends the dropdown wandering on the user interface. It makes it difficult to reach the intended choice.

Here is a video showcasing the behaviour
https://github.com/user-attachments/assets/1c9192e9-a499-4be9-94be-b464657516dc

Steps to reproduce

Go to any dropdown, click on it, scroll to reach an option whilst moving the mouse.
This is especially problematic on small screen with long dropdowns at the bottom of the page.

Expected behavior

The maximum position of the dropdown menu should be anchored at the dropdown's position either above or below. I.e. the dropdown should always touch the collapsed dropdown menu.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

darktable.org / GitHub release

darktable version

5.0.0

What OS are you using?

Windows

What is the version of your OS?

Windows 11 pro

Describe your system

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[dterrahe]

What this looks like is that the combobox popup receives scroll or arrow key events while the mouse is moving. A scroll up-or-down would activate the item in the list that's adjacent to the previously selected one and it then moves the whole list so that the newly activated item is under the mouse cursor. Could it be that you have some mouse utility running in the background that issues scroll commands based on mouse moves? The edge browser for example does something like that after middle-clicking. Maybe you have a tool that tries to do the same thing for other programs. It might be possible to disable it for just darktable, where such behavior is inappropriate.

If that is not what is happening here, we might need more information to replicate in order to be able to implement (and test!) a generic workaround.

[Artaga734]

I have no other utility known to me than standard Windows 11.
To be clear, in the video, I am moving the mouse cursor and scrolling at the same time to showcase the issue. The intent is to reproduce the issue.

The "standard" use case I faced is a combobox at the bottom of the screen and I want to reach options lower than what is displayed, so I move the mouse to the bottom and scroll to go search for additional options. In that case the whole list might disappear.

Naively I would think of constraining the combobox to be anchored on the actual button and its legend.

[dterrahe]

You described that you moved and scrolled at the same time quite clearly and I didn't read. Apologies!

There's another mechanism to avoid the scenario where you can't reach an item that's off the screen at the bottom or top; when you are nearing the edge of the screen, the list is supposed to move so that everything is visible. If that doesn't work for you, that would be a bug. One case where I'm aware this doesn't work is when running under WSL2 and forcing Wayland mode: the windows Wayland emulator doesn't provide screen edge information.

Your scenario where "the whole list might disappear" should not happen because at least one row should be visible under the mouse cursor (the one that is selected).

The intent behind moving the whole list when scrolling so that the selected item is under the mouse cursor is so that there's only one "highlighted" item that is changing. The alternative would be that the "active" item would change but if that was off screen, the list would have to move anyway to show it, but now a different item would be under the mouse cursor and get highlighted, to indicate that that one would get selected if you clicked.

Basically I'm trying to say that the thing is a product of compromises and that it's easy to fix one case, but that might then create other weird cases. One issue your suggestion would have is that the position of the underlying widget can change based on the selected item. For example, change the export file type by scrolling while the export module is glued to the bottom (by having a number of other modules above it expanded). The content of the export module will change depending on the file format and the format drop-down itself will move about. If that would trigger a relocation of the popup as you suggest, the popup might suddenly close because the mouse is not on it anymore. Anchoring it just to the original location of the widget might be possible. I'll keep it in mind in case at some point I feel like diving into the logic again and doing the extensive multi-platform testing each change requires. Or you could have a go at it yourself it you want. I'd be happy to review a PR.

[Artaga734]

No worries !

I get your point, and I think I can now imagine the underlying verifications and design considerations at play.
For now I don't have the skillset to give a go to this feature, but I would be happy to help test or participate to the specification of such changes.