Bug 425627 - When Dolphin crashes or is force-quit with Ctrl+Alt+Esc , tabs aren't saved
Summary: When Dolphin crashes or is force-quit with Ctrl+Alt+Esc , tabs aren't saved
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 20.08.0
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
: 449996 484782 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-08-21 08:05 UTC by Varaskkar
Modified: 2024-03-30 22:22 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 24.05


Attachments
Dolphin is about to be closed with Ctrl+Alt+Esc cursor (93.14 KB, image/jpeg)
2020-08-21 08:05 UTC, Varaskkar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Varaskkar 2020-08-21 08:05:35 UTC
Created attachment 131070 [details]
Dolphin is about to be closed with Ctrl+Alt+Esc cursor

Dolphin save the tabs if it's closed of normal way clicking on X up right corner in its toolbar.

But if Dolphin is closed with the shortcut Ctrl+Alt+Esc, we select the app we want to close. We put cursor on Dolphin app and click, then it's closed, but when start again don't appear its previous tabs anymore.

Also happen when laptop shut off suddenly by a outage. It happened to me recently.

It will be possible to save the tabs state when load the address instead of close the app?


Operating System: Manjaro Linux
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.8.1-3-MANJARO
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Comment 1 Nate Graham 2020-08-21 17:53:33 UTC
Currently, state is saved when the app quits, but this means it has to quit normally. If the app is force-quit or crashes, state doesn't get saved before the app dies.

Making the state saving more durable so that it handles cases like this makes sense. It would be a really nice touch for the user's state to not get lost even if the app crashes or the machine loses power or something (as happened to you).

To do this, we would need to also periodically save the state during normal use. Like, anytime a tab is opened or closed, or the view is navigated to another location, or a split view is opened or closed--that sort of thing.
Comment 2 Patrick Silva 2021-06-07 14:10:12 UTC
Still an issue with Dolphin 21.04.1 on Arch Linux.
Comment 3 Bug Janitor Service 2023-10-23 01:28:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/637
Comment 4 Stefan Brüns 2023-10-23 14:22:21 UTC
Ctrl-Alt-ESC is *not* a "shortcut to close", it is the shortcut to invoke xkill, or equivalent to forcefully terminate a hanging application.

Crashing is bad anyway, and saving more often is just a really ugly workaround.

Writing to disk recurrently is not a solution, it is against KDE ECO goals, and it introduces blocking synchronization points over the whole desktop (state saving requires flushing to disk and synchronization). This may be less notable with SSDs, but becomes an issue when you use HDD, eMMC or SD card for storage.

Proper solutions:
1. Educate people xkill etc. is not closing. Adjust the shown text to mention "All changes will be lost". This is not only about dolphin, but all applications.
2. Fix dolphin so it does not crash.
Comment 5 Felix Ernst 2023-10-26 11:12:13 UTC
*** Bug 449996 has been marked as a duplicate of this bug. ***
Comment 6 tagwerk19 2023-10-26 18:26:15 UTC
(In reply to Stefan Brüns from comment #4)
> ... Writing to disk recurrently is not a solution ...
Is it possible to save state in shared memory rather than written to disc? Something that is not owned by Dolphin and lost when Dolphin is killed, a "state rememberer" process of some sort?
Comment 7 fanzhuyifan 2023-11-02 16:55:23 UTC
As an alternative solution, how do people feel about adding a button for saving the user session?
Similar things are already proposed in https://bugs.kde.org/show_bug.cgi?id=306257

The user session for dolphin seems very non-essential. No important work is lost if it is not saved.
Hence, saving the user session periodically is just an overkill. It can introduce latency increases
with only marginal benefits.
Comment 8 Varaskkar 2023-11-02 18:14:17 UTC
It's true that the original idea is not efficient, because of writing to the disk continuously.

As an alternative, I think the button is a good idea, besides being simple for the user.

I agree with the proposal of the other ticket (306257). Something that can load several sessions and maybe give them a name like "Personal" or "Work", where each session has its own tabs, views or previously loaded configuration. It could be something like Activities in KDE, where you can have your own "working environment".
Comment 9 Henning 2023-11-02 23:07:21 UTC
I disagree, what size of file are we talking about?

This first issue is about bad UX, opened tabs being gone after bad closes. Saving it every like 3 minutes would not be a problem I think.

Having different profiles with names and alll is a different topic, not directly related.

It could be opt-out and I am still a fan of a Plasma "Energysaver" metasetting (blur, animations, etc) but it should automatically save.
Comment 10 Méven Car 2024-01-14 08:37:12 UTC
Git commit c035e95e1d74fecd8267b08009c616232e2c16b0 by Méven Car, on behalf of Amol Godbole.
Committed on 14/01/2024 at 09:34.
Pushed by meven into branch 'master'.

DolphinMainWindow: autosave session

Currently, the session is saved only when the app quits normally. Save
the session after a fixed time interval from the last state change i.e.
anytime the url is changed, or a tab is opened or closed, or the active
view is changed.

M  +65   -5    src/dolphinmainwindow.cpp
M  +18   -0    src/dolphinmainwindow.h
M  +2    -0    src/dolphintabwidget.cpp
M  +5    -0    src/dolphintabwidget.h
M  +2    -0    src/main.cpp

https://invent.kde.org/system/dolphin/-/commit/c035e95e1d74fecd8267b08009c616232e2c16b0
Comment 11 fanzhuyifan 2024-03-30 22:22:42 UTC
*** Bug 484782 has been marked as a duplicate of this bug. ***