Scroll wheel behavior on Tag Panel

Some versions back, I reported on a problem that occurred when using the mouse wheel while working in the Tag Panel. Sometimes, rolling the wheel when the pointer overlays a field's value, the value would change from the previously entered (and already written) text to <blank>. This behavior easily goes unnoticed, which is a serious issue.. The result is that further tag panel operations end up removing desired values from the affected field(s).

The problem was promptly fixed after I first reported it, but it appears that it has crept back into the code. It's the only way I can explain the fact that once-written tags disappear mysteriously, causing us to either (1) unknowingly omit critical metadata at completion, or (2) re-entering the tag field's values all over again.

Please make sure the mouse wheel is disabled when the pointer is in the body of the tag panel. Of course it would be nice if it still operates when the pointer is in the scroll bar region.

There is a difference between Mp3tag having the focus on a certain field on the Tag Panel and having the focus on the Tag Panel itself.

The former also enables the scroll wheel to switch between entries in the drop-down list. This is standard behavior on Windows. It's deactivated once the user starts editing in one field (as described by @JJ_Johnson's suggestion in [F] Tag Panel problems with 'wheel mouse').

The latter simply scrolls the whole Tag Panel (in case a scroll bar is visible). Further experiments with @ohrenkino in a private conversation have shown that this is only possible, if the Windows 10 setting "Scroll inactive windows when I hover of them" is enabled.

Not sure if it makes sense for me to reply here, but ... I essentially signed up to report this issue, but I see it's bubbled up a few times. Just adding my frustration at the current behavior - when I use the scroll wheel but am not focused on a select/dropdown, I expect the panel itself to scroll, and not the select/dropdown that happens to be underneath my mouse pointer at that moment. Is there any chance the scroll wheel could be ignored on those selects, unless they are currently focused?

mp3tag-mousewheel

I share your frustration. I posted this issue some time ago, but the response was that some people want to scroll through the list of items in the window. I was also told that this is "proper procedure" via Microsoft's "rules for mouse behavior.

Unfortunately, this is a serious problem for us when tagging or updating our digital music library file metadata... Our tag panel is quite long, and the last thing I want to do is accidentally change a field value while scrolling up or down the tag panel. To overcome this issue, I think user's should be able to change the mouse's scrolling behavior when in the "interior" of the tag panel—that is, the region where the field values are entered.

This cannot be difficult to do.

D2B ...

+1

I tried disabling the "Scroll inactive windows..." option in Windows 10 but the behaviour is still the same.

I agree with @redux and @dbd that this is weakness in the tag panel interface that can easily lead to unwanted / unnoticed errors. I could be wrong, but I've never noticed this behaviour in other applications, but then I scroll over dialogs much more in MP3Tag than anything else.

I agree 100%. I spoke about this several years ago but was told it was "normal" behavior for Windows. I would like to insist that this be fixed in mp3tag.

D2B ...

TBH, I don't know what should be fixed.
When I use the scroll wheel and the mouse cursor hovers over a piece of grey (background) area of the tag panel, then the whole panel scrolls.
This works until the panel has moved so far under the mouse cursor that the mouse cursor now hovers over a list box. Now the list box scrolls....
I would expect exactly that.

1 Like

That is precisely the problem. The list box should not scroll or change content unless you select the "down" arrow at the right end of the list box and deliberately select a different value, or if you intentionally type in different information.

I just checked with the program ACDsee (which means that I checked how the list box behaves there) and there the list box behaves just like in MP3tag: as soon as the list box has the focus, the scroll wheel scrolls through the list entries without the list box being expanded. So it looks to me like some common list box behaviour.

@ohrenkino That's a shame. My tag panel is very long so I use the mouse to scroll a lot when tagging and I keep getting caught out.

If I go into a Microsoft Office app, e.g. Word, and go to Options > Advanced, I get a long dialog with list box fields that exhibit the behaviour that I'd like to see in MP3Tag. When scrolling with the mouse, the dialog scrolls and not the contents of a list box as I start a scroll from it.

I am using a touchpad rather than a mouse, but I think the behaviour is equivalent.

In Office, when you start a two fingered scroll over any part of a scrollable dialog, the whole dialog scrolls, irrespective of whether you start with the cursor over a dropdown box or not, or whether the dropdown box has the focus. If you want to scroll a dropdown contents with the mouse, you click it to give it the focus, then single finger scrolling works (incidentally, the down-arrow gets a border to show it will get the focus if you click when the mouse is over it). Two-finger scrolling still scrolls the containing dialog. To me, this feels intuitive and consistent with what I normally see in the Windows interface.

In MP3Tag tag panel (which seems to be the only scrollable dialog in the app), if you need to make sure the mouse cursor is not over a dropdown if you want to scroll the whole dialog using two fingers. Also you need to click the down-arrow to see the list, whereas in Office, a single finger scroll will make the list appear and scroll to the option you want. :+1:

So, there is a precedent, and it is possible. Top of my wish list for MP3Tag usability.

I hope that this was helpful in explaining the issue.

Sorry @d2b about dbd :wink:

Thank you for the hint.
I aso scrolled through the long list - and yes: it did modify the contents of a combobox when it got the focus.
I explicidly had to open the combo box.
BUT: when I used the scroll wheel with the open combobox then the contents of the box stayed at the cursor and the other contents of the options window scrolled away ... The context for the opened combobox was completely lost.
I am not sure that I want that behaviour in MP3tag...

Another use case: open a browser on a page that features a map and scroll with the scroll wheel: as soon as the mouse cursor hovers over the map, the map is zoomed, no further scrolling happens for the rest of the page - until you move the mouse cursor to the scroll bars.

So MP3tag is by far not the only program that behaves in the criticized way.

You could place the tag panel at the bottom of MP3Tag. I personally prefer this arrangement. In this way you have more space horizontally for the columns of the column view and also less need to scroll vertically in the tag panel, since a screen is usually wider than it is high, especially with the 16: 9 or 16:10 dimensions that are common today.

1 Like

I never had the problem that the content of tag-fields got actually deleted because of changing to with the wheel mouse, because I noticed this always before saving.

But what really annoyed me several times was that I accidently changed the directory-field in the tag-panel this way and I had loaded my whole collection, which is very very large.
I takes quite some time to load the files again.
This tag-field and the filter-field are the only ones that have immediate (without saving) consequences after accidently changing them with the wheel-mouse.

In consequence I decided to disable the dircetory-field in my tag-panel.
I don't know how but I think it would be a good idea to change this behaviour.

Yes, that drives me crazy too :grinning:

Two-fingered scroll for the containing dialog and single-fingered for the combo is a benefit if you randomly access tag panel fields, so you avoid disrupting fields you scroll past. If you also start at the top and work down, there is less of a difference.

I got out a mouse just to ensure two-finger on touchpad is equivalent to the mouse wheel: it is.

In fact the behaviour between Office and MP3Tag is pretty much the same once the combo has the focus, except that Office allows you to scroll away when the mouse is over over the top line of the combo (like cancelling because you haven't changed anything).

@poster's suggestion of putting the tag panel at the bottom is a great work-around - I hadn't realized that was possible or how much better that layout works if you have a large tag panel.

BTW, I am not criticizing MP3Tag, this is just some usability feedback.

First of all, I agree that the behavior is not optimal. I think it's very obvious from @redux's post above. However, I'm not sure about what the optimal behavior might be, because there are always different interests at stake.

Preventing scrolling in this case would disrupt the workflow for all those that simply click into the field and use the scroll wheel (or two-finger scrolling) and expect the field to cycle through the different values. Also, typing is intentionally disabling scrolling to address [F] Tag Panel problems with 'wheel mouse' - #10 by JJ_Johnson.

I don't have Office, so it's a little bit hard to imagine. What do you mean by single finger scrolling? It sounds like this is just moving the mouse cursor, but it's probably a special feature of your touchpad. Do you know the equivalent of that when using the mouse?

One tricky bit is that the Tag Panel background can't get the focus by itself, there is always one field that has the focus. I prefer to keep it that way for all those who are mainly using the keyboard to navigate between the different UI parts.

I've tried finding some good native older Windows examples of panels/dialogs that have select dropdown style widgets, as well as being scrollable, but it seems that in general, Windows avoids having both a scrolling panel AND a select (e.g. going to device manager, getting to the details of a driver, there is a select dropdown that can be scrolled/changed directly with scroll wheel, but the panel itself is sized so that it doesn't need scrolling).

In newer-style panels in Windows 10, it seems that select dropdowns are simply not reacting to scroll wheel at all (for instance looking at the display settings)

settings-scroll

For what it's worth, even for web content, where you can have scrolling for the page and then actual <select> elements, it seems browsers ignore scroll wheel events on the selects.

web-selects

It may be a case of having to make a choice and suppressing mouse wheel functionality on the selects? having both the panel scrolling and the selects changing on scroll wheel is just the worst of both worlds at the moment / bad user experience.

EDIT: looking a bit closer at the new-style Windows settings panels, it seems (though it's a tiny bit flakey) that it's using some sort of heuristic - if the scrolling with scrollwheel started outside of the select, and is "in progress", the selects don't react at all to the scrollwheel. However, if the mouse started off over one of the selects, then scrollwheel is hijacked to just cycle throught the select options and not to scroll the page (though sometimes, the heuristic appears to flake out on recognising the "in progress" scrolling on occasions) windows-selects-scroll - further edit: ah, it seems that to trigger the second behaviour, the user has had to first click/focus into the select at least once ... only then does it do this heuristic. otherwise, scrollwheel just scrolls the page/panel regardless of where you started the scrollwheel action. anyway, this does appear to be a tough nut to crack / circle to square, as either way a change in behaviour will annoy one group of users that relied on the current one, despite solving the problem for another group of users that were annoyed by the current one. maybe...and i know this is usually the undecided/cowardly way out...make it a setting ?

1 Like

I've spent the day experimenting and working on that and I think I've found a sensible way of tackling this issue. Thanks @redux and everyone involved for the helpful examples and discussions around that.

This is the new behavior:

  1. Tag Panel scrolling using the scroll wheel doesn't capture the scrolling when hovering over one of the fields. It simply scrolls the Tag Panel. However:

  2. Clicking in one of the fields makes the scroll wheel cycle through the field's list entries if the cursor is above the field.

  3. If the cursor moves above the Tag Panel background, scrolling is back to move the Tag Panel.

  4. Clicking the drop-down also enables scroll-wheel scrolling.

  5. Entering data using the keyboard disables the ability to scroll using the scroll wheel to prevent accidental deletion of data. Using either key up or key down enables scrolling again.

I think that's it. Especially the idea to use click into a field to enable scrolling should also be in favor of those who like to use the scroll wheel to cycle to the fields contents. It's the best attempt to combine the two worlds, at least for today :slight_smile:

Here is a preliminary version for you to try and test:

https://download.mp3tag.de/support/BEC24A86-ECE4-4F65-BC75-A439E84B7B86-3-11-5-1/mp3tagv311e1setup.exe

Please note that any of that might change or be removed again for a final release in case problems with the new implementation appear and even if you're not affected by those.

Just took that preliminary version for a spin. Personally, I love it. Fingers crossed this makes it into the next release version. Thanks for the swift work there, Florian.

1 Like

I think so too. Good work.
You should add this to your list of "However":

  1. This does not affect multiline fields. These fields are always scrolled with the wheel if the cursor is on the field.

It think it is a good solution that multiline fields make an exception. With you present solution it is still possible to scroll within multiline fields without the need of clicking in the field.

1 Like

Yes, it’s equivalent to moving the mouse, and not a special function of touchpad.

Thanks for looking at this quickly. I’ll give it a try later on today.