Have managed to find workaround for time being (thanks frinring)

// fixes statusbar/menubar/toolbars
QApplication::setAttribute(Qt::AA_DontCreateNativeWidgetSiblings);
// fixes restoring root widget that contains Qt::WA_NativeWindow after
// calling KMainWindow->setupGUI()
rootDockWidget->show();

Using Qt::WA_DontCreateNativeAncestors on native window widget solved it not showing/restoring, but in combination with Qt::AA_DontCreateNativeWidgetSiblings has created painting issues.

Created attachment 113648 [details]
Simple app to reproduce the problem

I'm not sure why in this example statusbar, menubar and toolbar continue showing. In other app case they go away too and just central widget remains.

Thanks for the detailed investigation! Would you be interested in producing a patch?

Our documentation for this can be found at https://community.kde.org/Infrastructure/Phabricator

It might also be worthwhile to file a bug against Qt and see what the Qt folks have to say about it.

Yes, sure. Will have another good look at everything, to figure if there's some clean way to solve on kf5 side. If I don't come up with anything good, will create a ticket on bugreports.qt.io and try to solve it there.

Thanks so much, Max!

The patch here https://phabricator.kde.org/D13808

Have tried reproducing this issue using just Qt and their recommendation of saving window state in closeEvent(), and it works fine like that.
Change introduced in Qt 5.11.1 can make the child widgets hide() during destruction, but it seems that they always hide after closeEvent() was called.

Patch just makes sure that window settings are not saved at any point after closeEvent() was accepted.

FTR, VirtualBox (a plain Qt application) has a similar problem since Qt 5.11.1:
the toolbar and statusbar disappear on next start if you close the window via the close button. (http://bugzilla.opensuse.org/show_bug.cgi?id=1099589)

Reverting the mentioned Qt commit fixes it, but the patch proposed here does not (of course, as it doesn't use KMainWindow').

So this is not really specific to KMailWindow...

(In reply to Wolfgang Bauer from comment #7)
> So this is not really specific to KMailWindow...
Oops, I mean KMainWindow of course.

Created attachment 113693 [details]
Simple app to reproduce the problem - Corrected

Corrected the example app, statusbar, menubar and toolbar also break. SetupGUI() was supposed to be called after setting up all widgets, since that one restores settings from rc file.

(In reply to Max from comment #0)
I apologize i wrote something wrong here:
> Above commit changed things so window close event gets handled by child
> widgets sooner... widgets get destroyed (and hidden) before
> QApplication::saveStateRequest triggers KMainWindow::saveState().
> KMainWindow::saveMainWindowSettings() then calls
> QStatusBar/QMenuBar::isHidden() (which will return true) and updates rc file.

Widgets get destroyed (and hidden) before KMainWindow::saveMainWindowSettings() gets triggered. Also it doesn't get trigerred by QApplication::saveStateRequest in this case.

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

Have created a bug report upstream https://bugreports.qt.io/browse/QTBUG-69277

There's an update from Qt report... They don't think it's a Qt's bug.
https://bugreports.qt.io/browse/QTBUG-69277?focusedCommentId=411008&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-411008

For the record: I will advise distributions to revert the Qt patch until a proper solution is found (famous last words)

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

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

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

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

Git commit d35a88289513c0420863b80aa6c1cb7d2c6e978f by David Faure, on behalf of Mladen Milinkovic.
Committed on 17/07/2018 at 07:45.
Pushed by dfaure into branch 'master'.

Fix KMainWindow saving incorrect widget settings
In certain cases KMainWindow::saveMainWindowSettings() could have been
called after mainwindow started destroying itself. Window settings would
be saved with incorrect child widget states. e.g. some widgets would be
saved as hidden even if they were visible before destroying.

M  +4    -0    src/kmainwindow.cpp

https://commits.kde.org/kxmlgui/d35a88289513c0420863b80aa6c1cb7d2c6e978f

396339 still not fixed after installing patched package in Arch: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kxmlgui&id=a974176c369056d599cc91343ac9373801bceec3

(In reply to Daimonion from comment #20)
> 396339 still not fixed after installing patched package in Arch:
> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/
> kxmlgui&id=a974176c369056d599cc91343ac9373801bceec3

KMail does saveMainWindowSettings() from mainwindow destructor:
https://cgit.kde.org/kmail.git/tree/src/kmmainwin.cpp#n99
That is broken in Qt 5.11.1 regardless of kf5 patches. It should be fixed in kmail.

(In reply to Max from comment #21)
> KMail does saveMainWindowSettings() from mainwindow destructor:
> https://cgit.kde.org/kmail.git/tree/src/kmmainwin.cpp#n99
> That is broken in Qt 5.11.1 regardless of kf5 patches. It should be fixed in
> kmail.

Did you open a bug for kmail?

(In reply to andreas.sturmlechner from comment #22)
> Did you open a bug for kmail?

yes... have reopened Bug 396339 and added explanation there

Git commit 814f0db2a1ae5b15bf91909ce80a5d6792f9aeed by David Faure.
Committed on 31/07/2018 at 13:46.
Pushed by dfaure into branch 'Applications/18.08'.

Port to setAutoSaveSettings so that saving happens before hiding.

Summary:
See d35a882895 in kxmlgui for more complete explanation.
Related: bug 396339

Test Plan: kmail ; Alt+F4 ; kmail -> now the statusbar and toolbar are visible again

Reviewers: ngraham, elvisangelaccio, broulik, cfeck, mlaurent

Reviewed By: mlaurent

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D14454

M  +1    -5    src/kmmainwin.cpp

https://commits.kde.org/kmail/814f0db2a1ae5b15bf91909ce80a5d6792f9aeed

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

I'm still affected by this. Latest KDE because using Arch Linux.

How do I get the File, Edit and other menus back?

(In reply to Damian Nowak from comment #26)
> I'm still affected by this. Latest KDE because using Arch Linux.
> 
> How do I get the File, Edit and other menus back?

Which app did lose menus? You should probably edit (BACKUP FIRST) $HOME/.config/[YouAppName]rc and remove lines similar to 'xxxState=\x...bunch of binary values..\x....\x...'

Afterwards start the affected app again and it should restore your menu/window/widget visibility/layout to defaults.

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

(In reply to Mladen Milinkovic, Max from comment #27)
> (In reply to Damian Nowak from comment #26)
> > I'm still affected by this. Latest KDE because using Arch Linux.
> > 
> > How do I get the File, Edit and other menus back?
> 
> Which app did lose menus? You should probably edit (BACKUP FIRST)
> $HOME/.config/[YouAppName]rc and remove lines similar to
> 'xxxState=\x...bunch of binary values..\x....\x...'
> 
> Afterwards start the affected app again and it should restore your
> menu/window/widget visibility/layout to defaults.

As of April 2023, I proceed as suggested and removed the lines in questions but it didn't affect the menu options. Still some listed as 'no text'.
Btw. It's Okular where the corrupt menu happened.
Do I see it right, thus bug is known since 2018?

(In reply to Fred from comment #29)
> (In reply to Mladen Milinkovic, Max from comment #27)
> > (In reply to Damian Nowak from comment #26)
> > > I'm still affected by this. Latest KDE because using Arch Linux.
> > > 
> > > How do I get the File, Edit and other menus back?
> > 
> > Which app did lose menus? You should probably edit (BACKUP FIRST)
> > $HOME/.config/[YouAppName]rc and remove lines similar to
> > 'xxxState=\x...bunch of binary values..\x....\x...'
> > 
> > Afterwards start the affected app again and it should restore your
> > menu/window/widget visibility/layout to defaults.
> 
> As of April 2023, I proceed as suggested and removed the lines in questions
> but it didn't affect the menu options. Still some listed as 'no text'.
> Btw. It's Okular where the corrupt menu happened.
> Do I see it right, thus bug is known since 2018?

You're seeing what is described in bug https://bugs.kde.org/show_bug.cgi?id=468248 .. correct?
I'm not 100% sure that menu entries showing as "No Text" is duplicate of this bug - this bug was about menu bar, toolbars, statusbar becoming hidden/invisible.

I'm getting a little bit confused about this bug tracking.
I did not mark it as duplicate bug of this one.
I filed a new bug under # 468248, menu entries listed as 'no text'.
And beyond that I don't know how this bug tracking system is working. who reads it, who linked bugs and who looking into the reported bugs.
I'm just a humble user/reporter of a bug.
:-)