Filter box gets blocked after writing in it a new filtering expression

When I am focused in the box of the Filter and write anything, no matter if with or without Auto-apply filter option turned on, then that box gets blocked - i.e. it no longer registers movement of mouse wheel thus do not scroll through the list of filtering expressions. In order to unblock the mouse wheel for that feature I have to first click within the box

This happens also no matter if after writing a new expression I stay with focus / prompt in Filter box, hover mouse pointer somewhere or click on a file from presented list - a click within the box is always required in order for me to able to scroll the list with my mouse wheel

[Version 3.16 x64]

I do not see anything "blocking" the filter box.
A "blocking" would mean to me that no further input is ever possible.
This is not the case as functions are immedidately available after another click into the filter box.

The behaviour that you describe applies to any combo-box. As soon as you change to edit mode, mouse wheel scrolling is disabled.
You can recognize the edit mode that the selection disappears and the keyboard cursor appears.
If you click into that combo-box again, the mouse wheel functions are available again.

You may test this behaviour e.g.with any field in the tag panel where you cannot scroll to <keep> and <delete> once you have started editing. You would have to click into that field again or press Cursor down

So if I rephrase the original title of this topic from

Filter box gets blocked after writing in it a new filtering expression

to

Filter's list of filtering expressions gets blocked during writing a new one in Filter box

[which title I would like you edit now] and you will take notice of the facts that after writing in the box of the Filter it:

  • does not allow to go through its list - when user uses the scroll wheel;

  • does not allow to go through its list - when user uses the scroll wheel, even when hovering with mouse pointer over that very box;

  • does allow to go through its list - when user uses arrow keys;

  • does allow to go through its list - when user uses arrow keys, even when not hovering with mouse pointer over that very box;

then you will decide that Mp3tag has either:

A] a bug for mouse behavior

B] a bug for keyboard behavior

C] an intentionally dual behavior - that has a downside of forcing a user to remember overall what input works in which box and which does not, plus favorizes keyboard users

?

I do not see any bug at all but perfectly normal Windows behaviour.
Even though you many have noticed it just now, it has been like that for ages - hence, the test environment tag-panel.

This is all research that you could have performed prior to posting this thread.

It's intended behavior: after editing, the mouse wheel gets enabled in dropdown fields either by opening the list or pressing keys arrow up or arrow down.

Moved to #bug-reports:no-bugs

But intended by you - and you are not planning to change this?

Or is just how Windows behaves in regards to this - and would be very hard to change if at all possible?

I do not think that the developer has any obligations to disclose his plans to you how the program develops further.

As this function looks a lot like a function supplied by Windows, I would kindly ask you to forward your bug report to Microsoft and see how and what they answer and which planned dates they reveal to you.

Closed this topic, see Scroll wheel in Filter Box does not always work for previous discussion on this topic with OP.