Qt with https://codereview.qt-project.org/#/c/222255/ and GTK 3 windows snap back to their old size after they lose focus. The Qt change (part of 5.12) breaks Plasma as well.
I applied that one change on top of 5.11 everything seems fine? gtk3 windows I'm not finding them have an issue when I change focus, but they do jump when There is one relevant quirk based on our debug output. We send a lot of configure(someState, QSize()); when we're just updating the state (like active changing) > If the width or height arguments are zero, it means the client should decide its own window dimension. In kwin we take that to mean "use the last thing I sent you" which seems a sensible assumption, but that's not how toolkits interpret that line nor how other WMs behave. I shall: - update kwin to always send a size - try and build qt master and see if I can reproduce there
(In reply to David Edmundson from comment #1) > I applied that one change on top of 5.11 everything seems fine? Adding stikonas to CC as he initially discovered this. I'm not sure what the broken Plasma behaviour was - I believe popups appearing in the wrong place? > gtk3 windows I'm not finding them have an issue when I change focus, but > they do jump when when...? > There is one relevant quirk based on our debug output. > > We send a lot of configure(someState, QSize()); when we're just updating > the state (like active changing) > > > If the width or height arguments are zero, it means the client > should decide its own window dimension. > > In kwin we take that to mean "use the last thing I sent you" which seems a > sensible assumption, but that's not how toolkits interpret that line nor how > other WMs behave. > > I shall: > - update kwin to always send a size > - try and build qt master and see if I can reproduce there That sounds like a reasonable explanation for the GTK behaviour at least.
I was building suspense. gtk3 windows I'm not finding them have an issue when I change focus, but they do jump when I start a new resize
Yes, I saw plasma windows at the top left corner: https://bugs.kde.org/show_bug.cgi?id=396650
what do you mean by "plasma windows" ?
(In reply to David Edmundson from comment #5) > what do you mean by "plasma windows" ? If I remember correctly, e.g. surface that opens when I click on "K-menu" (or if I click on calendar, plasma-nm, etc.)
Reproduced for plasma windows. Regular windows are fine. I think the GTK window situation might be a different bug.
More related but different bugs :( I've identified the source of the GTK bug that bothers me the most. We block so that we only send one configure request until we get a damage event, in an attempt to keep things synced. In some cases we send configure with the same size twice; this will cause no surface commit, and our lock holds indefinitely until we cause a repaint. I don't want to do the fix of addressing the requests we send, but instead making us more robust to blocking. Ideally by removing the blocks and just tracking configure/acks correctly.
So back on the Qt issue with 5.12 QWindow->setPosition(10,10) on wayland does nothing but window->position() still returned 10,10 in new Qt it returns 0,0 (or rather it does after ack which is a bit weird) because it didn't really move anything. To a large extent, this change is quite sensible. but the magic plasmashell protocol relied on it. I'll submit a Qt patch and see what happens, otherwise we have a tonne of plasma work cut out for us.
There are two bugs. The geometry issue, but also Qt's geometry updates can deadlock and then never show windows a second time \o/ https://bugreports.qt.io/browse/QTBUG-70845?focusedCommentId=424274&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-424274 The first issue is arguably us relying on quirky behaviour, the second is a bug for definite. Unfortunately the underlying bug is only exposed in plasma dialogs and not simpler test cases.
That more worrying deadlock bug is now fixed. I wrote a review for the other one: https://codereview.qt-project.org/#/c/241711/ Not convinced it'll get in worst case I'll upload a workaround to p-f.
Both Qt patches merged \o/ 5.12 latest is all good to go.