Bug 158934 - Media ejecting fails to update the location bar
Summary: Media ejecting fails to update the location bar
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
: 373834 427648 427649 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-07 22:11 UTC by András Manţia
Modified: 2020-11-16 18:12 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In: 20.12


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description András Manţia 2008-03-07 22:11:46 UTC
Version:            (using Devel)

Insert a media, click on its name in Places, navigate in some folder inside the media. E.g. the location shows:
Media Icon > Folder1 > Folder2

Click on the media icon and eject the media. The content disappears, but the location does not change. You can actually click on Folder2, Folder1, and the navigation bar updates correctly, you just don't get content and get an error in the status bar. The Media Icon changes to "Root icon" and you see:
Root > media > Folder1 > Folder2 
though.

Expected behavior: after ejecting, switch to the /media folder or at least to / (and update the location bar as well).

The bug is present in both Navigation and Editable mode.
Comment 1 Michael Stather 2009-01-21 23:45:50 UTC
I'd switch to the "home" location as it's more universal.
But remaining in the empty folder in /media is a bug also because it's possible that the user doesn't notice that the device is unmounted (e.g. if the device was empty before, then the contents view doesn't change at all) and tries to create folders or add files in the /media dir with no device mounted.
Comment 2 Shaun Reich 2009-02-15 22:08:40 UTC
I agree, this problem is still present in early 4.3, pushing it to kdelibs, as it is on their end of things. Dolphin uses the KFilePlacesView, which is what this is. Changing to the root directory would probably be the best in my opinion.

The problem probably lies in KFilePlacesModel::requestEject() (or something of the like), because this is where it becomes ejected, just a guess, although I am not sure how one could go about forcing the currently selected item to the root one. Doing this would also have to trick down and emit the urlChanged() signal, so that Dolphin can receive this and interpret it also.
Comment 3 Michael Stather 2009-02-15 23:53:15 UTC
If you change it, IMHO change it to the folder which is set as default when dolphin starts, not to a specific one. Just my 2c ;)
Comment 4 Shaun Reich 2009-02-16 00:06:24 UTC
Hm, well that could add a cog in the wheel, I am thinking. Since it is outside Dolphin's control of when a media gets ejected. We'll figure out how to go about this, hopefully when a higher-up developer sees this.
Comment 5 Dawit Alemayehu 2013-06-15 14:47:39 UTC
For the record both Dolphin and Konqueror now displays an error message if you attempt to navigate the directory of an already removed drive. By comparison both Windows 7 and OSX automatically close the window that was showing the contents of the removable device when it is ejected.
Comment 6 Nate Graham 2017-09-05 02:30:05 UTC
Seems to behave as expected now in newer versions of Dolphin and KIO.
Comment 7 Patrick Silva 2017-09-06 19:11:53 UTC
Are you sure?
https://bugs.kde.org/show_bug.cgi?id=373834
Comment 8 Nate Graham 2017-09-08 02:19:27 UTC
*** Bug 373834 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2017-09-08 02:20:10 UTC
Oops, you're right.
Comment 10 Patrick Silva 2018-03-31 16:27:58 UTC
Related: when an audio cd is ejected, dolphin is still showing its content.
Comment 11 Patrick Silva 2018-08-18 12:38:15 UTC
Still valid for Dolphin 18.08 on Arch Linux.
Comment 12 Patrick Silva 2018-11-20 14:12:56 UTC
Still valid for Dolphin 18.12 beta.

Operating System: Arch Linux 
KDE Plasma Version: 5.14.3
Qt Version: 5.12.0 beta4
KDE Frameworks Version: 5.52.0
Comment 13 Patrick Silva 2020-01-26 20:59:13 UTC
Still happening with Dolphin 19.12.1 after I unmount or eject removable devices
and unmount partitions of an internal hard disk.


Operating System: Arch Linux 
KDE Plasma Version: 5.17.90
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.0
Kernel Version: 5.4.14-arch1-1
OS Type: 64-bit
Processors: 2 × Intel® Celeron® CPU G1820 @ 2.70GHz
Memory: 7,7 GiB of RAM
Comment 14 Nate Graham 2020-10-13 15:22:12 UTC
*** Bug 427619 has been marked as a duplicate of this bug. ***
Comment 15 Bug Janitor Service 2020-10-13 17:56:24 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/76
Comment 16 Nate Graham 2020-10-13 18:31:16 UTC
*** Bug 427649 has been marked as a duplicate of this bug. ***
Comment 17 Nate Graham 2020-10-13 18:32:27 UTC
*** Bug 427648 has been marked as a duplicate of this bug. ***
Comment 18 Elvis Angelaccio 2020-10-23 17:00:37 UTC
Git commit ae1d441dacef7e52984201abdc9a918ce060021c by Elvis Angelaccio, on behalf of Nate Graham.
Committed on 23/10/2020 at 17:00.
Pushed by elvisangelaccio into branch 'master'.

Show home folder if needed after unmounting mounted disk

Right now, when you unmount a device that any active view containers are
displaying, nothing in the view changes. As a result, it's possible to
try to navigate to files or folders in that view, which cannot be done
because the disk that the files or folders are located on has been
unmounted!

With this commit, we detect that case and switch the view containers
to show the home folder after the disk whose contents they are displaying
gets unmounted.
FIXED-IN: 20.12

M  +19   -0    src/dolphinmainwindow.cpp
M  +9    -1    src/dolphinmainwindow.h
M  +3    -0    src/panels/places/placesitemmodel.cpp
M  +1    -0    src/panels/places/placesitemmodel.h
M  +2    -0    src/panels/places/placespanel.cpp
M  +1    -0    src/panels/places/placespanel.h

https://invent.kde.org/system/dolphin/commit/ae1d441dacef7e52984201abdc9a918ce060021c
Comment 19 Riccardo Robecchi 2020-10-24 21:35:49 UTC
(In reply to Elvis Angelaccio from comment #18)
> Git commit ae1d441dacef7e52984201abdc9a918ce060021c by Elvis Angelaccio, on
> behalf of Nate Graham.
> Committed on 23/10/2020 at 17:00.
> Pushed by elvisangelaccio into branch 'master'.
> 
> Show home folder if needed after unmounting mounted disk
> 
> Right now, when you unmount a device that any active view containers are
> displaying, nothing in the view changes. As a result, it's possible to
> try to navigate to files or folders in that view, which cannot be done
> because the disk that the files or folders are located on has been
> unmounted!
> 
> With this commit, we detect that case and switch the view containers
> to show the home folder after the disk whose contents they are displaying
> gets unmounted.
> FIXED-IN: 20.12
> 
> M  +19   -0    src/dolphinmainwindow.cpp
> M  +9    -1    src/dolphinmainwindow.h
> M  +3    -0    src/panels/places/placesitemmodel.cpp
> M  +1    -0    src/panels/places/placesitemmodel.h
> M  +2    -0    src/panels/places/placespanel.cpp
> M  +1    -0    src/panels/places/placespanel.h
> 
> https://invent.kde.org/system/dolphin/commit/
> ae1d441dacef7e52984201abdc9a918ce060021c

I honestly don't find this an improvement - if anything, I find this a regression. It has happened to me that a disk was unmounted without me noticing (e.g. because of an issue with the cable I was using). Having an error message was actually useful to realise that something was not working. If you redirect users to the /home folder, there's no indication that the position they were in is not available anymore; plus, the user does not reasonably expect to see the /home folder after a device or folder has been unmounted.
There is also a peculiar, but nonetheless valid, use case in not being moved away from the folder: if you need to unmount a device and then remount it, it is rather useful to not have to navigate a possibly intricate tree of folders again. With the current behaviour you can just update the view; with the new one, you have to navigate again to the desired position.
I know this is a bit like XKCD's famous "I press the space bar to heat my room" thing, but I am really opposed to the new behaviour as it does not solve the issue and just sidesteps it with a solution that doesn't feel right.
Comment 20 lesto 2020-10-24 21:52:10 UTC
> Having an error message was actually useful to realise that something was not working.

currently there are no error messages

> if you need to unmount a device and then remount it, it is rather useful to not have to navigate a possibly intricate tree of folders again

i agree
Comment 21 Elvis Angelaccio 2020-11-05 23:17:32 UTC
(In reply to Riccardo Robecchi from comment #19)
> 
> I honestly don't find this an improvement - if anything, I find this a
> regression. It has happened to me that a disk was unmounted without me
> noticing (e.g. because of an issue with the cable I was using). Having an
> error message was actually useful to realise that something was not working.
> If you redirect users to the /home folder, there's no indication that the
> position they were in is not available anymore;

I'm not sure what is the problem here honestly.
You will realize that the disk is not available anymore the next time you try to read from or write to it, no?

> plus, the user does not
> reasonably expect to see the /home folder after a device or folder has been
> unmounted.

That's standard behavior in other filemanagers. Windows even close the whole file explorer window IIRC.

> There is also a peculiar, but nonetheless valid, use case in not being moved
> away from the folder: if you need to unmount a device and then remount it,
> it is rather useful to not have to navigate a possibly intricate tree of
> folders again. With the current behaviour you can just update the view; with
> the new one, you have to navigate again to the desired position.
> I know this is a bit like XKCD's famous "I press the space bar to heat my
> room" thing

Kind of, yes :) Why not add this frequently accessed path to a place/bookmark?
Comment 22 Patrick Silva 2020-11-14 11:27:16 UTC
This bug is still happening when I eject an optical disc (DVD).

Dolphin 20.12 beta
Operating System: Arch Linux
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Comment 23 lesto 2020-11-14 14:31:45 UTC
> You will realize that the disk is not available anymore the next time you try to read from or write to it, no?

i agree a alert should be printed

> That's standard behavior in other filemanagers. Windows even close the whole file explorer window IIRC.

yes, and is good and bad.

The idea of closing it is nice IF you also automatically open it (consistency in behavior, if you open it, you close it, but do NOT touch my stuff!), and this could be expanded to "if i opened a folder keep it open".

I see 2 use case where not going to home can be useful, but just show an alert: 

- i have different SD card, and sometimes i need to cycle over them to find a piece of data i need. I can quickly see as soon as i see the content if it is what i am looking for (file name has date + specific label), so by keeping the folder open i will:
- pop in a SD card
- open the folder
- is not is, remove it (should be safe as there are no write, get the alert sd card unmounted)
- pop in the next one, the folder refresh to the new content

I guess this is also what i would expect is i change cd-rom in the reader.

Another advantage is that if i have many tab/folder open and i have different remote mount (or a junky sd card reader) i can see exactly what mount point is being problematic and not do guesswork. To be fair in this point can be also fixed by explicitly saying what mount point failed in the error message
Comment 24 Jonathan Marten 2020-11-14 19:49:34 UTC
+1 to suggestions in comment #23.  The indication could be a KMessageWidget near the top centre of the window, saying something like:

   The device <DEVICE> containing this folder
   has been unmounted from <MOUNTPOINT>

with the "warning" palette and icon.
Comment 25 Nate Graham 2020-11-16 17:25:31 UTC
Can you please open a new bug for this? Optical media typically requires different special handling.
Comment 26 Patrick Silva 2020-11-16 18:12:23 UTC
(In reply to Nate Graham from comment #25)
> Can you please open a new bug for this? Optical media typically requires
> different special handling.

Done, see bug 429207