Regression: panel launcher position are not stored after moving the launcher about mate-panel

[lukefromdc]

With a row of 8-10 launchers between the menu and window list left side of a bottom panel, on Debian Unstable I've never had trouble with launcher positions not being saved. When I get home tonight will test a 2nd panel many launchers and nothing else on it. If they stay put we need to find out what is different between my case and where the problem appeas

[raveit65]

Here is a small video (862,1 KB) with 5 panel launcher in a row. See what happens.
https://www.dropbox.com/scl/fi/k1fdbvadyev9vu2xvfvy4/panel_launcher-2024-01-28_17.44.08.mp4?rlkey=dm70h5ugzwgtp2g6wo63h90jw&dl=0
This is with collection menu enabled, but the issue still exists without collection menu.
Edit:
A smaller version (416,5 KB) https://www.dropbox.com/scl/fi/no6zhvc3pn4lgso64qjbq/panel_launcher-2024-01-28_17.44.08-small.mp4?rlkey=aft54fa15f978k73vpf4n4zsu&dl=0
I use a classic layout for the top panel.
Classic menu, some launchers (default fedora panel layout), the newly added launchers, volume applet (default layout), tray-applet, clock-applet.
Panel is compiled in-process.

[lukefromdc]

Just tested with a row of launchers on a top panel for testing. May have seen this issue once, then could not duplicate it (under wayland anyway) even under same conditions as the video. Will now try it in x11

[lukefromdc]

A little easier to invoke it under x11 (though sample size is small here), but was not consistant. Seems that it's when launchers are "spring loaded" against oneanother is when this is most likely to happen. The reason I've never seen this before then would be the fact that all of my normal launchers are part of a hand packed arrangement that avoids the "springy" condition entirely on the left side of the panel.

This part of the code (applet spacing) is not one I have much of an understanding of.

[raveit65]

@thesquash
Huston we got a problem.