This can be easily reproduced: 1. maximize a window 2. bring a small window that does *not* cover the panel to the front/focus 3. click to open a menu and then to close it 4. the panel jumps out and in again in this case (in Gtk2 it simply remains visible, which is the correct behavior)
I cannot reproduce the steps you listed, but I think it's related to this bug: - Use the Intelligent hiding - Focus a maximized window - Hover to panel and open any plugin properties dialog The panel will flicker quickly before the dialog is open. I'm also able to reproduce this on Xubuntu 17.04, but glitch is less noticeable and only happens about half of the times. Probably the fix to this to make the panel reluctant to hide, idk maybe introduce a small delay (e.g. 500ms) before hiding, need to check how well this would work on a Window Manager with animations.
There already is a delay but it's not working anymore in Gtk3 and this may actually be the source of all problems...
From what I've been able to find out so far it seems that window moves take immediate action now whereas in the past they were executed through calls to gtk_widget_queue_resize.
Reading in the gtk_window_move docs it could also be that this is a behavioural change in Xfwm4.
@Andre: The behavior you describe is also reproducible with 4.12/Gtk2, so not a regression.