Filter box does not take notice of user editing a tag field or is unable to block itself then

Bug Reports Fixed Bugs
#1

How to prepare settings for this bug [in version 3.16]

#1] Create some filtering expression; or make sure you have some existing ones

#2] Load many test files - don't try this on anything of value

#3] Left click in the box of filter


How to experience variant A:

#4] Move mouse pointer to the top file. [It does not have to be the one at the very top but it will be easier to evoke the bug]

#5] Start editing some tag field of that file - but do not accept the change yet

#6] Move pointer back over to the Filter box

#7] Start scrolling mouse wheel

#8] Choose whatever expression - but make sure that it will allow you to see at least one file in the main window

#9] Observe how the edited field stays floating like a ghost despite list of files in main windows is changing

#10A] Press Esc to stop that bug that; or

#10B] Press Enter to accept change of data

Result: edited data from tag field of another file gets saved in the current top-file, while that original file stays untouched

Possible additional outcome: sometimes it may be impossible to undo changes with CTRL + Z [happened to me only once]


How to experience variant B:

#11] Move mouse pointer somewhere near the bottom of the list

#12] Start editing some tag field of some file - but do not accept the change yet

#13] Move pointer back over to the Filter box

#14] Start scrolling mouse wheel

#15] Choose whatever expression - but make sure that it will allow you to blank space [.i.e. lack of files] near the bottom

#16] Observe how the edited field stays floating like a ghost despite list of files in main windows is changing

#17A] Press Esc to stop that bug that; or

#17B] Press Enter to accept change of data

Result: no data changes but you get a reward in form of a pop-op window with error message, as Mp3tag apparently just tried to edit tag field of file made of anti matter


Explanation:

a] Filter box does not take notice of user editing a tag field

b] Filter box does take notice of user editing a tag field - but is unable to cancel editing mode

c] Filter box allows for change of filtering expression - which should not be happening because Filter is suppose to be in some sort of temporary state of suspension

Mp3tag Development Build Status
#2

I can confirm this behaviour and even provoke a crash.
For the crash the hovering field has to float over the white empty area in the file list after the filter has been applied.
A click into the file list then leads to the crash.
Mp3tagError.log (1,9 KB)

To get the behaviour at all it is vital to
first click into the filter box,
then start editing,
then move the mouse cursor to the filter box without clicking and
then use the mouse wheel.

#3

This is now fixed with Mp3tag v3.16b. Thanks for reporting and for reproducing the issue.