Qwerky behavior with playlist+album art resizing

[travibe]

Hello, everyone. Forgive me if this issue has been reported previously, but I just came across this bizarre behavior and felt like I needed to inform the powers that be of the bizarre nature of what program window is doing.
So this happened after I created a new playlist view (specifically: missing metadata) and I had been adding/removing/moving columns to the single simple view area. I then went to resize the playlist and album art slider that resizes that side of the window. I click and hold the mouse button down, resized the panel to the left, and released the mouse button. The panel is then the new size i wanted it. However, I was going about my business and inadvertently passed the mouse cursor over that resizable line of the playlist/album art, and the mouse cursor changed to the resizing cursor without having to click the mouse button. The panel then begins to resize only when the mouse moves to the left, increasing the size of the panel It does not do this moving to the right. No matter what I would do, this behavior would continue until i clicked that small arrow in the bottom right that collapses Winamp into mini mode or whatever its called.
It's really obnoxious. I hope I'm explaining this adequately. I attached an image that hopefully helps explain what I'm describing, I circled the part of the window I'm talking about that kept resizing in red.

WACUP version 1.99.52.24626
Windows 11 insider edition 26300.8935

[dro]

I can't replicate it from trying to follow the steps mentioned & you've said playlist view when local library view is what I assume you meant based on what the image shows. If it is consistently happening for you then it's not something I can easily fix (especially not if I can't replicate it so far) as that part of the ui is handled by the re-used gen_ff (modern skin engine) plug-in dll from the winamp 5.666 installer.

[travibe]

I took it upon myself to report this because I have been using Winamp (original version and now WACUP) since Winamp was first released and I have never seen it before. I know you guys have a never ending list of bugs to replicate and fix, and was under the impression that it was probably going to be due to something introduced in some change to the original code, perhaps easier to find and fix than some old bug that was never resolved. I don't know, stupid logic. I'll keep an eye open to see if it happens again, otherwise it was probably something brilliant I did, 
Just trying to help, not make more work for you.

[dro]

I wasn't having a go about reporting it as I'd rather know than not since it's just me trying to make wacup. I was just trying to say without rambling that late in the night for me that because it's coming from a plug-in that I don't have the source code for when it does weird things more often than not there's little I can actually do to try to workaround it's problems. As what you've reported has to be down to the plug-in deeming that the ui element had the mouse focus but didn't see it being taken by something else causing it to then react in the manner it did when going back over it which is something I've seen in other win32 coding but so far I'm still not seeing it happen with the steps given.

[travibe]

Ok i understand better now. I for a moment thought you meant something I added 3rd party, but now I just realized that most everything in winamp is derived from a plugin and then assembled. That makes more sense.
On a side note, I've been seeing you doing this project for so many years now, and gotta say, it impresses the hell out of me that you have taken this on all on yourself. I never knew i had such an emotional attachment to a piece of software until I tried to find  something worthy of replacing this gem, and I never could. Thank you for all your years of effort, man. You aren't an asset to this community, you are the community.