GNOME Bugzilla – Bug 753351
notifications about removable devices being safe to remove stay after reboot.
Last modified: 2016-02-29 12:10:21 UTC
If I eject a usb stick, I get a notification that the device is safe to remove. the notification does not go away from the message tray once I remove the device. I have to manually clear it. Since the entry is also stored in ~/.local/share/gnome-shell/notifications, the notification stays even after a reboot (assuming I did not manually remove it). Maybe clear notifications about removable devices once those particular devices have been removed.
(In reply to Hussam Al-Tayeb from comment #0) > If I eject a usb stick, I get a notification that the device is safe to > remove. the notification does not go away from the message tray once I > remove the device. How do you eject the device? We only save/restore app notifications using the GNotification API, and it's up for applications to withdraw them as appropriate.
(In reply to Florian Müllner from comment #1) > How do you eject the device? We only save/restore app notifications using > the GNotification API, and it's up for applications to withdraw them as > appropriate. The leftside pane in Nautilus.
(In reply to Hussam Al-Tayeb from comment #2) > The leftside pane in Nautilus. So this is a nautilus issue, or rather it would be, if the code hadn't been removed recently[0]. Moving to GTK+, where the notification has been moved to. [0] https://git.gnome.org/browse/nautilus/commit?id=ede7b0c3217262
Carlos, are you or Georges going to look at this ? It just requires us to call gtk_application_withdraw_notification somewhere, I assume.
If I don't come up with a patch up to Thursday, consider that I won't be able to make it on time.
If there is anything I can help test, I am more than glad to do so.
*** Bug 753553 has been marked as a duplicate of this bug. ***
Bug 753553 is about the notification popping after resuming from suspend.
So gtk+ does the device handling? shouldn't gtk+ only receive calls to show/take off notifications and the client app such as nautilus decide when?
Created attachment 312976 [details] [review] gtkplacessidebar: use finalize instead of dispose Just to be sure we don't receive any widget signal after dispose. I think in this case we don't need to use dispose specifically, since no circular refs are present, and in this way we are more in the safe part.
Created attachment 312977 [details] [review] gtkplacessidebar: withdraw notifications on finalize We were not withdrawing the notifications at all, which is confusing when the notification is still there after a reboot or after the application is closed. To avoid this withdraw all notifications generated by the sidebar on finalize.
Patch in comment 10 is unrelated...but wanted to get review.
I applied those two patches to the gtk+ 3-18 branch and rebooted. The issue is still there. ejecting says wait till data is written then the message changes to you can now unplug htc android phone. strings ~/.local/share/gnome-shell/notifications org.gnome.Nautilus gtk-mount-operation-0x1e24e10 title You can now unplug HTC Android Phone body icon themed media-removable (sv) priority normal s 0<k a{sv}
Review of attachment 312977 [details] [review]: ::: gtk/gtkplacessidebar.c @@ +2694,1 @@ This doesn't look like it can work - you are allocating a string when you add the notification to this list, and here you create a different copy. The g_list_remove has no idea you are dealing with strings, so it won't call strcmp to decide the two copies are the same... even if the remove worked, you are leaking the string in the list.
Created attachment 313118 [details] [review] gtkplacessidebar: withdraw notifications on finalize We were not withdrawing the notifications at all, which is confusing when the notification is still there after a reboot or after the application is closed. To avoid this withdraw all notifications generated by the sidebar on finalize.
Same issue (both patches). I hear the sound event when I unplug the phone after unmounting (so gnome knows the device was unplugged) but notification stays. I rebooted and notification is still there. strings ~/.local/share/gnome-shell/notifications org.gnome.Nautilus gtk-mount-operation-0xf0fc60 title You can now unplug HTC Android Phone body icon themed media-removable (sv) priority normal s 0<k a{sv}
From irc cosimoc> mclasen, csoriano__, IMO it's not a good idea to withdraw notifications from the finalize of the sidebar mclasen, csoriano__, the lifecycle should be tied to the GApplication if anything mclasen suggests to just not notify from the library in the first place cosimoc> that would also work csoriano__> mclasen: I actually would go that way cosimoc: so return the code to nautilus again?
Would putting the code back in nautilus affect the ability to mount/unmount from gtk filepicker?
Every time I wake up my laptop, I get a generic notification for my cloud.gnome.org account. It doesn't say anything except the name of the account, and clicking it opens Nautilus. It's pretty annoying to get these notifications each time. Debarshi suggested that this bug might be the cause.
(In reply to Allan Day from comment #19) > Every time I wake up my laptop, I get a generic notification for my > cloud.gnome.org account. It doesn't say anything except the name of the > account, and clicking it opens Nautilus. > > It's pretty annoying to get these notifications each time. Debarshi > suggested that this bug might be the cause. That's gnome-shell automount.
(In reply to Carlos Soriano from comment #20) > That's gnome-shell automount. I'm not so sure about that - that's not a notification that should show up when coming back from suspend, not to mention that I do have cloud.gnome.org set up and don't see that notification :-)
(In reply to Florian Müllner from comment #21) > (In reply to Carlos Soriano from comment #20) > > That's gnome-shell automount. > > I'm not so sure about that - that's not a notification that should show up > when coming back from suspend, not to mention that I do have cloud.gnome.org > set up and don't see that notification :-) uh strange, neither nautilus nor gtk+ launch a notification when mounting.
@Allan Day, that's exactly what Bug 753553 was about which was closed due to this bug.
Florian, The fact that the notification doesn't dissapear (as noted in Bug 753553) automatically (so priority critical) makes me think even more it's gnome-shell notification.... gtk+ and nautilus only use notifications with default priority.
*** Bug 757813 has been marked as a duplicate of this bug. ***
Hello. Which component does the actual 'unmounting'? gvfs? Perhaps gnome-shell should read from 'gvfs -> udisks' that the device disappeared and remove the notification?
Created attachment 317416 [details] [review] gtkplacessidebar: remove notification We were showing a notification from gtk+ when a volume was unmounted from the sidebar. However the notification is preserved after reboot, which is kind of odd. Also, it feels odd that the a GUI library is showing notifications, which looks something more for the application or gnome-shell side. So remove the notification from gtk+.
(In reply to Carlos Soriano from comment #27) > Created attachment 317416 [details] [review] [review] > gtkplacessidebar: remove notification > > We were showing a notification from gtk+ when a volume was unmounted > from the sidebar. > However the notification is preserved after reboot, which is kind of > odd. > Also, it feels odd that the a GUI library is showing notifications, > which looks something more for the application or gnome-shell side. > > So remove the notification from gtk+. Will gnome-shell issue the notification in that case or is it gone completely?
it's up to the application doing the unmounting.
Review of attachment 317416 [details] [review]: hm I think better at least show a spinner in the same place as the eject button... so reject this patch
(In reply to Carlos Soriano from comment #30) I applied the patch to my gtk 3.18.6 installation. The notifications are gone. However now plugging in my phone (USB Mass storage) auto-mounts it. I don't think it auto-mounted in the past. > Review of attachment 317416 [details] [review] [review]: > > hm I think better at least show a spinner in the same place as the eject > button... so reject this patch Yes. An non-intrusive indication within the places dialog that drive is busy or in progress of unmounting or safe to unmount would be elegant.
Ah. Nevermind. Gnome-shell actually shows a warning dialog if I try to unmount a busy drive. So perhaps just a "in-mid unmounting" spinner in the places panel.
*** Bug 759710 has been marked as a duplicate of this bug. ***
*** Bug 759711 has been marked as a duplicate of this bug. ***
Created attachment 321284 [details] [review] gtkplacessidebar: remove notification handling We were notifying when an unmount operation was performed. However, creating notifications from the gtk+ library is not that expected, and makes notification handling difficult to do from the application point of view since we cannot dismiss those notifications. This cause issues like notifications of unmount drives stay there after a system reboot, which confuses the user. Instead of that, remove the notification handling for mount operations on gtk+ and instead create a new signal on the gtkplacessidebar in order to inform applications using it about an operation about to start. Only drawback about this is that the GtkFileChooser loses its notifications when unmounting, that although we could use the new signal to do it, we actually don't want to notify from any part of gtk+ for now.
an upcoming nautilus patch will implement the notification handling there.
Created attachment 321285 [details] [review] gtkplacessidebar: remove notification handling We were notifying when an unmount operation was performed. However, creating notifications from the gtk+ library is not that expected, and makes notification handling difficult to do from the application point of view since we cannot dismiss those notifications. This cause issues like notifications of unmount drives stay there after a system reboot, which confuses the user. Instead of that, remove the notification handling for mount operations on gtk+ and instead create a new signal on the gtkplacessidebar in order to inform applications using it about an operation about to start. Only drawback about this is that the GtkFileChooser loses its notifications when unmounting, that although we could use the new signal to do it, we actually don't want to notify from any part of gtk+ for now.
Last patch fixed a small typo.
Review of attachment 321285 [details] [review]: ::: gtk/gtkplacessidebar.c @@ +4308,3 @@ + /** + * GtkPlacesSidebar::mount-operation: mount-operation is not a great name for a signal, imo. ::change-mount or ::mount-or-unmount would be better names. Could even make that 2 separate signals, and go for ::mount and ::unmount @@ +4314,3 @@ + * The places sidebar emits this signal when it starts a new operation + * because the user ejected some drive or clicked on some location that + * needs mount. should read: needs mounting. @@ +4315,3 @@ + * because the user ejected some drive or clicked on some location that + * needs mount. + * In this way the application using the #GtkPlaccesSidebar can track the Typo: Placces
Created attachment 321370 [details] [review] gtkplacessidebar: remove notification handling We were notifying when an unmount operation was performed. However, creating notifications from the gtk+ library is not that expected, and makes notification handling difficult to do from the application point of view since we cannot dismiss those notifications. This cause issues like notifications of unmount drives stay there after a system reboot, which confuses the user. Instead of that, remove the notification handling for mount operations on gtk+ and instead create a new signal on the gtkplacessidebar in order to inform applications using it about an operation about to start. Only drawback about this is that the GtkFileChooser loses its notifications when unmounting, that although we could use the new signal to do it, we actually don't want to notify from any part of gtk+ for now.
Good idea Mathias, even more since we don't know from the GMountOperation whether it's a mount or not, separating the signals allow us in case we want to handle them separately. Also, as a side not, I'm increasing to think would be a good idea to do all the mounting notification inside nautilus (as a gapplication service), and remove the gnome-shell mount notification part.
Created attachment 321373 [details] [review] gtkplacessidebar: remove notification handling We were notifying when an unmount operation was performed. However, creating notifications from the gtk+ library is not that expected, and makes notification handling difficult to do from the application point of view since we cannot dismiss those notifications. This cause issues like notifications of unmount drives stay there after a system reboot, which confuses the user. Instead of that, remove the notification handling for mount operations on gtk+ and instead create a new signal on the gtkplacessidebar in order to inform applications using it about an operation about to start. Only drawback about this is that the GtkFileChooser loses its notifications when unmounting, that although we could use the new signal to do it, we actually don't want to notify from any part of gtk+ for now.
Attachment 321373 [details] pushed as b8e2ebb - gtkplacessidebar: remove notification handling
This problem is still in there but now it's not gtk+'s fault. gtk+3.19.10 nautilus 3.19.90 and gnome-shell 3.19.90
(In reply to Hussam Al-Tayeb from comment #44) > This problem is still in there but now it's not gtk+'s fault. Then why reopen a gtk+ bug for it ?