I noticed this issue too when working on windowing improvements to KWinFT. Dolphin sends for some reason a configure request with a seemingly random size after the compositor already has restored it.

Can't reproduce, but I can believe it happens. It probably has something to do with the new position-restoring code I added a few months ago.

talentlcy, as a data point, are you also using KWinFT or another KWin fork, or the original KWin?

Also can you (you meaning anyone who can reproduce the issue) attach your ~/.config/dolphinrc file while the app is maximized, and then again after the app is restored?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

(In reply to Nate Graham from comment #2)
> Can't reproduce, but I can believe it happens. It probably has something to
> do with the new position-restoring code I added a few months ago.
> 
> talentlcy, as a data point, are you also using KWinFT or another KWin fork,
> or the original KWin?

Sorry for the late reply. I am using the original Kwin. 

I solved this problem dont remember when by adding the URL navigagtor to the Kwin toolbar, which moved the address bar from the folder view to the toolbar, then suddenly everything is doing well. So I think this problem is related to the URL navigator. To verify my hypothesis, I removed the URL navigator from the toolbar,then problem recurred again.

Created attachment 135339 [details]
dolphinrc

(In reply to Nate Graham from comment #3)
> Also can you (you meaning anyone who can reproduce the issue) attach your
> ~/.config/dolphinrc file while the app is maximized, and then again after
> the app is restored?

Having uploaded my dolphinrc in attachments.

Found the issue. Will submit a merge request soon.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kconfig/-/merge_requests/47

Git commit b57c7ad9acf45928a6debefcd432cc50432fefdb by Nate Graham.
Committed on 02/02/2021 at 14:40.
Pushed by ngraham into branch 'master'.

Fix restoring window size when closed while maximized

The maximization string was being saved to the config file including
the connected screens, but the code to read it was not, and was also
looking for the old incorrect format. This could have resulted in old
config values being used forever, and the window always being opened
in a maximized state.
FIXED-IN: 5.79

M  +2    -2    src/gui/kwindowconfig.cpp

https://invent.kde.org/frameworks/kconfig/commit/b57c7ad9acf45928a6debefcd432cc50432fefdb

Can confirm works now with KWinFT. Thanks!

Phew!

*** Bug 432594 has been marked as a duplicate of this bug. ***

*** Bug 434825 has been marked as a duplicate of this bug. ***

Exactly the same issue and the same workaround for me.
Unfortunately, even if this is marked as fixed, it is not for me.
Do you ever sorted it out?

I also still notice the bug.

Dolphin Version: 21.04.1
KDE Frameworks: 5.82.0
Qt 5.15.2

Please attach a screen recording of the problem happening so we can be sure it's the same thing, and not some other bug.

Made a new video with updated dolphin ans same results as the already reported bug you can still read about there: https://bugs.kde.org/show_bug.cgi?id=434825

The new video is available at:
https://www.youtube.com/watch?v=iW2k1Ezu1H8

I've to point out that not only:
* Dolphin fails to restore the original size
* Dolphin shrinks the leftside panel for no apparent reason

But also, when the window resize effect is enabled (at about 00:43 in the video), the location bar fails to resize properly too when resizing the window.  

All the observments made for bug 434825 remains still.
It can be closed as a dupe of this one, because the root cause smells the same.

*** Bug 434825 has been marked as a duplicate of this bug. ***

REOPENED and marked https://bugs.kde.org/show_bug.cgi?id=434825 as a duplicate for this.

I can confirm this bug in Plasma 5.22.2, and the URL Navigator workaround "fixes" it.

I also suffer from this regression.
How come this regressions go to major releases?
Developers do not use dolphin or do not use maximize or don't use Places panel? No idea.

Very disturbing issue, please avoid regressions like that (breaking basic things) as it eliminates all awe of new things in new versions, when you have something broken each major release.

P.S. I see a possible fix was made by Nate Graham. Thanks a lot!
Can someone tell what exact Dolphin version should have fixes of this regression and #434825?

The bug description says: "Version Fixed In: 5.79".

It must be wrong, because I have Dolphin 20.12.2 with KDE Frameworks 5.79.0 and it's not fixed for me.

Also the version should be Dolphin-related, should not it?

For anyone still experiencing the bug, can you try moving aside your ~/.config/dolphinrc file and trying again? This will check to see if stale config file entries could be causing the bug.

(In reply to Nate Graham from comment #24)
> For anyone still experiencing the bug, can you try moving aside your
> ~/.config/dolphinrc file and trying again? This will check to see if stale
> config file entries could be causing the bug.

Yep, starting from a newly generated file, it works as intended, as stated here:
https://bugs.kde.org/show_bug.cgi?id=434825

However, the "intended" way raised some concerns about the  removal of the search bar, quoting myself:

>  Also, the decision to move the url navigation widget 
> to the toolbar raises problems for the ones that 
> like to have text in the toolbar itself, because
> enabling it breaks url navigation widget
> alignment with the file view area.
> moving the url navigation thing outside 
> of the toolbar raises the described problem again.

> Another thing i noticed when i deleted dolphinui.rc,
> is that the -previously present- "search toolbar", went gone.
> It could be handy because one can use it to
> accomodate url navigation bar, sacrifying some 
> space for the places panel.

https://bugs.kde.org/show_bug.cgi?id=434825#c10
https://bugs.kde.org/show_bug.cgi?id=434825#c11

...so basically the ones left with an old working configuration file have to choose to have resize problems (keep old file) or possibly disalignment of widgets when their sizes don't fit the intended position (...)

I think the right way of handling this change would be the ability to keep the search bar and have dolphin able to properly resize itself, not asking users to delete their -previously working- configs.

I understand the needs to simplify things, but not when that breaks working environments.
This is happening more and more lately (Sorry.).

If you restore your old config file and remove all the lines in it that BEGIN with "Window-Maximized", does the problem go away?

I've no lines beginning with "Window-Maximized", but i've just this:
"HDMI1 HDMI2 Window-Maximized 800x600=true"
Deleted, killed dolphin, but the problem persisted.

Hmm, can you attach your dolphinrc config file from a time when the bug is happening?

Hi Nate, i've attached one in the past in the other bug report:
https://bugs.kde.org/show_bug.cgi?id=434825
https://bugs.kde.org/attachment.cgi?id=137023

Created attachment 140348 [details]
dolphinrc

(In reply to Antonio Orefice from comment #29)
> Hi Nate, i've attached one in the past in the other bug report:
> https://bugs.kde.org/show_bug.cgi?id=434825
> https://bugs.kde.org/attachment.cgi?id=137023
Ok, it was "dolphinui.rc", and was the one causing problems.
However, i'll attach you dolphinrc too from a dolphin that fails to restore window size when unmaximized.
In both files there is no line starting with "maximized".

Sorry for the confusion,
I've to retract my observations in comment 25 about ~/.config/dolphinrc, (i read and spoke about dolphinui.rc, ,sorry)
Removing ~/.config/dolphinrc, does not change a thing.

Sorry for the noise, everything stated in comment 25 was about dolphinui.rc which i think is the root of the problem.

Created attachment 140350 [details]
other resize problems when in dual panel mode

I've found that even using standard/shipped config files, there are widget resize problems when using dual panel view.
This should be vanilla dolphin.

See the video attached, I explicitely delete the config files, then i show the bug.

Info given

Thanks for the config file. I still cannot reproduce the issue even when I use it on my own Dolphin. :( I notice that you have a dual monitor setup, and I have a single monitor setup. I wonder if that could be related. Can you try unplugging one monitor and see if that helps?

> I've found that even using standard/shipped config files, there are widget resize
> problems when using dual panel view.
Let's use this bug report to track the issue with size restoration after un-maximization, rather than adding other issues to it as well. That will just confuse us. :)

Unfortunately on single screen setup (another system) things do not change.
About the other thing i reported, i think they are related in the way that "dolphin is unable to correctly resize internal widgets anymore (used to work in the past)", and i think the problem in restoring the window size (and shrinking the places panel) depends on that.

(In reply to Nate Graham from comment #34)
> Thanks for the config file. I still cannot reproduce the issue even when I
> use it on my own Dolphin. :(

Given the config files posted, a way (not the only way) to reproduce the bug is:
#1 shrink the dolphin window width to the minimum allowed,
#2 maximize and unmaximize it.
That triggers the window size bug, has the left panel has already been shrinked in step #1
Different combination of window size and places panel sizes triggers the window size bug *and* the places panel size bug

I bisected the issue, but even if i found the "bad" commit,
it is not much useful, because it just exposes a bug introduced earlier and i cannot determine when using git bisect:

In the past, the location bar were under the tabs, near the places panel.
Then it was moved to the top and the users were not allowed to move it.
Then the "bad" commit (not bad at all) 50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1, allowed users to move the location bar where it was by simply removing the location bar from the main toolbar.

So, I understood that dolphinui.rc is NOT needed to reproduce the issue, it just contained the information that the location bar was NOT present in the main toolbar, and as soon as the commit landed, that setting took place exposing the resize bug.

So the bad commit could be anywhere between:
37327c9b0aae112c5890703cba1f0157043007e0 (Make UrlNavigators in the toolbar the only option)
and
50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1 (Allow having the UrlNavigators below the tab bar)


---------------------------------------------------------------------------------------
koko@Gozer# git bisect bad
50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1 is the first bad commit
commit 50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1
Author: Felix Ernst <fe.a.ernst@gmail.com>
Date:   Thu Nov 19 21:22:27 2020 +0000

    Allow having the UrlNavigators below the tab bar
    
    This commit restores the possibility to have the UrlNavigators below
    the tab bar. This will happen automatically whenever the UrlNavigator
    is removed from the toolbar.
    
    It is also now again possible to have the toolbar on the side. This
    option is disabled while the toolbar contains the UrlNavigators.
    
    This commit makes no changes to the new default which is having the
    UrlNavigators in the toolbar but makes sure that upgrading users won't
    be affected.

 src/dolphinmainwindow.cpp             | 35 ++++++++++++++++++---
 src/dolphinmainwindow.h               | 13 ++++++++
 src/dolphinnavigatorswidgetaction.cpp | 58 +++++++++++++++++------------------
 src/dolphinnavigatorswidgetaction.h   | 23 +++++++++-----
 src/dolphintabpage.cpp                | 23 ++++++++++++--
 src/dolphintabpage.h                  |  2 ++
 src/main.cpp                          |  7 -----
 7 files changed, 110 insertions(+), 51 deletions(-)
---------------------------------------------------------------------------------------

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/250

Git commit 7edce5a09c768805878d15e225cd063fb037cef3 by Elvis Angelaccio, on behalf of Felix Ernst.
Committed on 01/08/2021 at 21:57.
Pushed by elvisangelaccio into branch 'release/21.08'.

Fix width issues when un-maximizing Dolphin

Before this commit un-maximizing or to be more precise instantly
changing the size of the window by a large amount could potentially
change the width of the sidebars, the viewContainers and the window
itself to unexpected/undesired widths.

This happened because the spacing calculation is triggered when the
primary ViewContainer is resized but at this point in time some of
the other widgets, especially the secondary ViewContainer and the
navigatorsWidget have generally not been resized yet. Therefore the
width and spacing calculations are based on partly updated and
partly outdated values leading to wrong results.

This commit makes it so calculation of spacings is delayed until
all widths have been updated.

Yes, spacing probably should not have the power to resize the
window but unfortunately the spacing can not be set to be less
forceful when taking space because otherwise the UrlNavigators
will take all space they can get with their
QSizePolicy::MinimumExpanding.
FIXED-IN: 21.08

M  +12   -1    src/dolphinnavigatorswidgetaction.cpp
M  +6    -0    src/dolphinnavigatorswidgetaction.h

https://invent.kde.org/system/dolphin/commit/7edce5a09c768805878d15e225cd063fb037cef3

*** Bug 434825 has been marked as a duplicate of this bug. ***

*** Bug 440382 has been marked as a duplicate of this bug. ***

Thanks, restoring now works correctly.