Can't select label which has a selection-dotted-border which isn't selected

I'm using the latest beta to fix the file-bar issue but I experienced this bug in the previous "stable" release so may as well mention it...

It always happens when I am editing labels and then move back up to the top.. The top or top + 1 selection gets stuck where the uncolored selection border sticks but the highlighted-row can be moved. When you try to click on the row which still has the border, it selects it for a brief moment before deselecting ( but the border remains and this behavior repeats until you close and re-open settings )... You can use the arrow keys to navigate to the affected row..

The easiest way to replicate is to change the order of the category which causes the program to select the row and lock onto it ( if you click apply the row will still be selected but if you click it again it won't let you without using the arrows or reopening settings -- you can't simply change screens nor can you try to set focus to another element; it will be stuck even if you change the order again by renaming a different label )

Open Settings > Favorites > Labels

Choose any label in any category
Edit the name so as to re-organize the list such as putting an A in front of a label which contains a z... ( Mine are Garry's Mod Client|Menu|Server Realm [ 3 labels ], Garry's Mod NoLoad, Garry's Mod SHARED via [ combo of client, server, menu realms - 3 labels ] ), and Lua file.
Click apply to cause the current label to be affected by bug... OR Click ANY other label in ANY category to cause the bug to affect that label until settings is re-opened...

NOTE: Clicking a category to make it roll up or down will not invoke the bug..

Examples:
If I change Lua file, which is at the end of the list to aLua file then click apply... aLua File is affected...
If I change Lua file, which is at the end of the list to aLua file then click on Garry's Mod NoLoad ( which is 3rd from the top prior to aLua File taking first place )... Garry's Mod NoLoad ( now in 4th position ) is affected...

Another Note ( as I can't edit my post ): If the list is NOT reorganized, the bug is not induced... The order must change for this bug to occur ( In case I wasn't specific enough in the pretext )...

Confirmed. I have reproduced that. Thanks for reporting it; we will get it fixed.

Cheers!

That has been fixed for the next update.

+1