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.

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.

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 ;)

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.

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.

Seems to behave as expected now in newer versions of Dolphin and KIO.

Are you sure?
https://bugs.kde.org/show_bug.cgi?id=373834

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

Oops, you're right.

Related: when an audio cd is ejected, dolphin is still showing its content.

Still valid for Dolphin 18.08 on Arch Linux.

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

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

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

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

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

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

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

(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.

> 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

(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?

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

> 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

+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.

Can you please open a new bug for this? Optical media typically requires different special handling.

(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