Bug 449988

Cannot reproduce on X11 with System Settings and Firefox.

Does it happen for you with all windows, or only some?

Does it happen on Wayland too, or just X11?

Created attachment 146616 [details]
Firefox window shrinkage

Created attachment 146617 [details]
Firefox window shrinkage

Created attachment 146618 [details]
Kate window shrinkag3

All windows using X11, don't use Wayland.

Using Oxygen Application Style, Plasma Style and Window Decorations.

Created attachment 146619 [details]
System settings shrinkage

Changed Global theme to Breeze Dark, no change, still happening.

Are you trying to recreate with a non Arch package base?

I don't use Arch, no. But that shouldn't be relevant here.

I have more than 10 arch systems over multiple machines, both virtual and non virtual.

This is happening on all of them.

If you cannot replicate this then it is relevant.

Created attachment 146681 [details]
New crash information added by DrKonqi

systemsettings5 (5.18.5) using Qt 5.12.7

- What I was doing when the application crashed:
Changed application style to bb10bright and system settings crashed. and now it crashes every time  selecting any appearaance related settings.

-- Backtrace (Reduced):
#4  QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::operator-> (this=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:118
[...]
#7  QObject::property (this=this@entry=0x0, name=name@entry=0x7f9549c63973 "_pixmapstyle_combobox_pressed") at kernel/qobject.cpp:3970
#8  0x00007f954998d1e4 in QPixmapStyle::drawComboBox (this=0x557ed7c92de0, option=0x557ed84e5a50, painter=0x7ffc9dc05e40, widget=0x0) at styles/qpixmapstyle.cpp:960
#9  0x00007f95199ffbb5 in KQuickStyleItem::paint(QPainter*) () from /usr/lib64/qt5/qml/org/kde/qqc2desktopstyle/private/libqqc2desktopstyleplugin.so
#10 0x00007f95199fffdc in KQuickStyleItem::updatePolish() () from /usr/lib64/qt5/qml/org/kde/qqc2desktopstyle/private/libqqc2desktopstyleplugin.so

It looks like we fixed wayland, but broke x11 along the way..

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2009

Git commit 8e05732670b07b82986f1d3e5ff59ad11bc1a4ec by Vlad Zahorodnii.
Committed on 14/02/2022 at 14:00.
Pushed by vladz into branch 'master'.

x11: Fix shrinking window size after toggling no border multiple times

The first move() in X11Client::createDecoration() will alter the client
size, which will result in the subsequent resize() incorrectly resizing
to a smaller window size.

In order to fix that issue, this change makes X11Client adjust the
frame geometry atomically after creating or destroying window decoration.

M  +2    -4    src/x11client.cpp

https://invent.kde.org/plasma/kwin/commit/8e05732670b07b82986f1d3e5ff59ad11bc1a4ec

Git commit d4068754c91f17f01e430f60bfed8975c7170977 by Vlad Zahorodnii.
Committed on 14/02/2022 at 14:30.
Pushed by vladz into branch 'Plasma/5.24'.

x11: Fix shrinking window size after toggling no border multiple times

The first move() in X11Client::createDecoration() will alter the client
size, which will result in the subsequent resize() incorrectly resizing
to a smaller window size.

In order to fix that issue, this change makes X11Client adjust the
frame geometry atomically after creating or destroying window decoration.


(cherry picked from commit 8e05732670b07b82986f1d3e5ff59ad11bc1a4ec)

M  +2    -4    src/x11client.cpp

https://invent.kde.org/plasma/kwin/commit/d4068754c91f17f01e430f60bfed8975c7170977

Thanks for the fix.

Will be in 5.24.1?

That's what the "Version fixed in" field says, no? :)

Yeah, my bad.

Created attachment 146796 [details]
No border old behavior, prior to 5.24

Created attachment 146797 [details]
New behavior with 5.24

Still not working properly.

The window size with no border is still smaller than the original window.  It should be the same size, at least that was the old behavior, which I believe is correct.

See the old behavior vs new behavior video attachments.

Borderless window contents should expand into the old window size with borders.

(In reply to hugh from comment #21)
> Still not working properly.
> 
> The window size with no border is still smaller than the original window. 
> It should be the same size, at least that was the old behavior, which I
> believe is correct.
> 
> See the old behavior vs new behavior video attachments.
> 
> Borderless window contents should expand into the old window size with
> borders.

Not sure why window size is kept constant in < 5.24, code doesn't try to do that, it actually tries to do the opposite. Regardless of that, the original issue (constantly shrinking window size has been fixed), please file a new bug report as it can be confusing to track multiple issues in one bug report.