https://bugs.kde.org/show_bug.cgi?id=525237
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDSINFO |REPORTED Resolution|WORKSFORME |--- --- Comment #5 from [email protected] --- Thanks for testing, and for merging the other three fixes. You're right about the steps as I wrote them: I can't reproduce them on master either. I built master (f1f75253) and ran it fullscreen against a local krdpserver in a nested KWin 6.7.5 session (Qt 6.11.2, Fedora 44) with scripted pointer input, on both the wayland and xcb backends. When the toolbar is dragged to the left edge and the pointer moves away, it auto-hides to the normal 6px strip at the new edge, the same as at the top, and hovering brings it back. My steps were written against the old xcb drag path, which your event() override now bypasses. The "same root cause: floatingtoolbar.cpp:248" line in the report was also wrong (see bug 525236 comment 3). The code my fix targets is still reachable another way. When the bar is already visible, reposition() sets endPosition = getOuterPoint(). After a drag nothing consumes that value, because hide() sets its own target. But the anchor's Resize eventFilter calls showAndAnimate(), which calls reposition() and then starts animTimer, and that drives the bar to the off-screen point. Steps to reproduce on master (both backends): 1. Connect to any host and go fullscreen. 2. Show the toolbar, click "Stick Toolbar", and move the pointer away. The toolbar stays, as expected. 3. Change the display scale, e.g. 100% -> 125%. Actual: the toolbar slides fully off-screen with no 6px strip left. Hovering any edge doesn't bring it back, because d->visible is still true. Changing the scale back doesn't either, since every resize repeats the slide-out. I only tested scale changes, but any resize of the fullscreen window (resolution, rotation, a different monitor) takes the same path. Without "Stick Toolbar", the same happens if the pointer is resting on the toolbar at the moment of the resize. On xcb it comes back as the 6px strip once the pointer moves. On wayland it stayed gone. Fix, tested on master with both backends: diff --git a/floatingtoolbar.cpp b/floatingtoolbar.cpp index 629fd728..2e91aa21 100644 --- a/floatingtoolbar.cpp +++ b/floatingtoolbar.cpp @@ -214,7 +214,12 @@ bool FloatingToolBar::event(QEvent *e) bool FloatingToolBar::eventFilter(QObject *obj, QEvent *e) { if (obj == d->anchorWidget && e->type() == QEvent::Resize) { - showAndAnimate(); + // showAndAnimate() ignores calls while already showing, which would drop a + // resize that arrives mid-animation and leave the bar placed for the old size + if (d->animState == Showing) + d->reposition(); + else + showAndAnimate(); return true; } @@ -411,7 +416,7 @@ void FloatingToolBarPrivate::reposition() endPosition = getInnerPoint(); } else { currentPosition = getInnerPoint(); - endPosition = getOuterPoint(); + endPosition = getInnerPoint(); } q->move(currentPosition); } The second hunk is the change from comment 1. The first is needed on xcb. A scale change there delivers two Resize events back to back: a transient size (1024x640 or 1600x1000 in my test), then the real 1280x800. The second arrives while the first is still animating, so showAndAnimate() returns early and the bar stays centred for the transient size. Calling reposition() in that case re-targets it. With both changes the toolbar stays docked and centred through the scale changes on both backends, auto-hides normally once the pointer leaves, and the drag scenario from the original report behaves exactly as on master. Feel free to retitle this. Something like "Fullscreen toolbar slides off-screen and can't be recovered after the window is resized (e.g. display scale change)" would fit better now. I'm happy to open a merge request if that's easier. -- You are receiving this mail because: You are watching all bug changes.
