SUMMARY Dolphin resets to "Home" and forgets paths of all tabs that are not available on start. The session gets completely lost and even making places available again do not help to restore information what were the locations of tabs. STEPS TO REPRODUCE 1. Set "Show on starup" setting to "Folders, tabs, and window state from the last time" in "Startup" settings of Dolphin. 2. Mount something to some directory, e.g. to /home/user/my/ 3. Open several tabs with sub-directories of this mounted place. 4. Close Dolphin 5. Unmount the directory 6. Open Dolphin OBSERVED RESULT Dolphin shows several tabs but all of them have "Home" name and no saved path. Information about previous session is lost. User has several useless "Home" tabs instead and that's all. EXPECTED RESULT All tabs should keep the paths even if those are not currently available (it can be remounted and session won't be lost). It always worked like that in previous versions of Dolphin. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 33. Dolphin: 20.12.2 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION It's a regression, because on older versions of Dolphin I had a red banner that location is not available with ability to make it available and refresh the tab.
I'm afraid this is an intentional change; we had many complaints about Dolphin showing annoying "this path cannot be found" messages on launch when attempting to restore tabs for inaccessible locations.
> we had many complaints about Dolphin showing annoying "this path cannot be found" messages on launch when attempting to restore tabs for inaccessible locations. Please revert this regression. The reasons: 1) The message was not annoying, it was banner at the top, not some modal messagebox. This message still exist if you delete the directory that is opened in tab. And that's fine, perfect. 2) If there are really people who were annoyed with "not found" message, then are using some unmounted directories and and now they should be pleased having 7 empty tabs of "Home"? Makes no sense. 3) And the most important - the session is lost! It's a loss of information, it is not acceptable, it's like deleting user files. Because location can be very important - those can be some directories that user was working in and will FORGET about it after this information is discarded. Nate Graham, can something be done to revert the current behavior? I will be wokring against this wrong decision. If you need someone the be convinced about this decision being wrong - please tell me. Who are those people who like to loose their information and have empty tabs anyway?
Furthermore, tabs exist not only in the Dolphin, but other applications too, like browsers. And NO browser closes/resets user tab's URL because it is not currently accessible. It will be strange and awful behavior, when you have disappearing tabs and have no information available what was there. Please reconsider.
I uses the feature that tab keeps it path and do not reset it. I could have remount location and continue to work with it. So closing Dolphin was not a problem at any point. And now it's a disaster.
Nate Graham, can you response? I love Dolphin and want it to be better.
https://community.kde.org/Get_Involved/Issue_Reporting#Have_realistic_expectations :) I am on vacation right now and responses will be delayed.
Thanks for reply, have a great vacation. I do have limited expectations, but this feature already was implemented and is kind of crucial in my user-case. With the whole save-session feature of Dolphin I could have relied on - just close Dolphin and continue from the last place. Even if place is not mounted - I could have just remount and F5 tab - I have my progress saved. Now if I open Dolphin when I forgot to mount disk - I have 7-10 tabs Home. OK, maybe there are some people who prefer saving session but loosing unavailable locations on startup. How about adding a checkbox in settings: "On startup close tabs with unavailable location"? It would allow these people and people like me who used reliable sessions to coexist happily.
OK back. Your use case is reasonable, and I think we can revisit this. The original point of the feature was to switch to ~ when you ejected a disk that was visible in Dolphin, to prevent it from either showing now-inaccessible contents or immediately displaying an error message. But perhaps it was over-broad to apply this to other inaccessible paths on login.
Great, that's really appreciated! I really loved reliable save-session feature and use tabs to remember what I have to do (path of tab means a lot). I have this ideas you may find useful: 1) Maybe the redirect to home should not happen on session restore, only it the path because unavailable in progress 2) And maybe only the current tab should be affected because it is more explicit? 3) Maybe the redirect to home should always be reversible by Back function. E.g. not change the path, but save current path to history and only then "go to home", so Back button will allow the come back to unavailable place. I hope for any solutions that would preserve my use case. Thanks again.
Thanks for opening the bug, I was going to raise the same issue. I regularly connect to a NAS and mount the remote filesystem manually after login. Indeed just like my web browser, I might keep 10+ tabs open to different locations relate to projects etc. My original workflow was to hit F5 in each tab after I mounted my remote filesystem. I appreciated how easy it was to just hit one button to refresh without needing to click any dialogs. In comparison to the terrible situation in Windows 10 with the same setup of remembering windows explorer folders on startup, if the NAS is not connected I'll get dozens of angry blocking popup messages saying it couldn't connect to the location, followed sometimes by the original window being automatically closed after acknowledging the message. Back to Dolphin, would be happy to revert to a situation where it remembers each tab's previous alocation and I can just press F5 to refresh if it is unavailable at any time. Even cooler would be a Meta-F5 "Refresh all tabs" to save me some clicks
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/248
Git commit ea7d4f059d5cb81b51053e7fec6492a727a968c2 by Nate Graham. Committed on 28/07/2021 at 18:59. Pushed by elvisangelaccio into branch 'release/21.08'. Revert "Don't session-restore invalid paths" This reverts commit c733b3aa9787a618a0ce5bb03b3fc731f5663b21. There are people who prefer the old behavior of session-restoring all paths including the ones which are currently inaccessible. The idea is that Dolphin is like a web browser; if a website is not currently available, the browser tells you that instead of silently discarding the URL and showing you the homepage. Doing this can be considered a form of data loss. In addition, the reason for the change was to prevent Dolphin from showing invalid paths on launch for unmounted removable disks, but that specific case was fixed separately by switching to ~ for any tabs/views that were showing locations on a just-unmounted removable disk. So you will never run into the problem if yo unmount a disk in Dolphin and then close it. Accordingly, let's revert the change because it causes more problems than it resolves. Related: bug 427619 FIXED-IN: 21.08 M +0 -14 src/dolphinmainwindow.cpp M +0 -6 src/dolphinmainwindow.h M +0 -4 src/main.cpp https://invent.kde.org/system/dolphin/commit/ea7d4f059d5cb81b51053e7fec6492a727a968c2
It is again with Dolphin Version 23.04.1 on update to Fedora 38.
(In reply to Thomas from comment #13) > It is again with Dolphin Version 23.04.1 on update to Fedora 38. Thanks for reporting! When this issue with loss of users information (paths of tabs) happened the last time Nate Graham made it work again and it was very appreciated! I really hope this time Nate again or somebody else will be able to once again fix this issue before I get to this version of Dolphin.
Same for me. Wasn't sure if my settings are just messed up because of rolling updated (Arch linux). Would love to see this fixed as my daily workflow depends on this feature.
I'm also seeing this behavior. All my historical tabs from YEARS are now gone in Dolphin and they ranged across many different storage locations. :(
Fedora 38 distro.
Same here, Dolphin version 23.04.1 on KDE neon 5.27 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9
Can somebody please find the commit that cause this issue again? Maybe this commit should be reverted until its author fix the introduced regression in their commit?
All comments starting from comment 13 are about https://bugs.kde.org/show_bug.cgi?id=469656 which is unrelated to this old bug.
(In reply to Thomas from comment #13) > It is again with Dolphin Version 23.04.1 on update to Fedora 38. It has been working again since yesterday (update). Version 23.04.2. :-)
Created attachment 159764 [details] attachment-920510-0.html I have installed 23.04.2. If I kill my dolphin session and restart, I do not get the correct behavior. If I close dolphin, I get correct behavior. The kill -9 which happens on reboot is not preserving session information. The On Sun, Jun 18, 2023 at 7:04 AM Thomas <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=439864 > > --- Comment #21 from Thomas <Thomas.Rausch@gmx.de> --- > (In reply to Thomas from comment #13) > > It is again with Dolphin Version 23.04.1 on update to Fedora 38. > > It has been working again since yesterday (update). Version 23.04.2. > :-) > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I have this bug dolphin behaviour too with : SOFTWARE/OS VERSIONS Linux/KDE Plasma: Mageia 9. Dolphin: 23.04.1 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.7
(In reply to Sebastien Chopin from comment #23) > I have this bug dolphin behaviour too with : > > SOFTWARE/OS VERSIONS > Linux/KDE Plasma: Mageia 9. > Dolphin: 23.04.1 > KDE Frameworks Version: 5.105.0 > Qt Version: 5.15.7 With actual Dolphin Version 23.04.3 no Problem.