Yes, that's because they're marked as urgent...I remember this was done on purpose in the design phase; if I remember correctly the problem is once the notification slides into the "Removable devices" item in the tray, you also lose the autorun choices, which need to stay visible instead. So I'd say this could be closed as NOTABUG.

Jon, what do you think?

So the bug would rather be that the autorun choices shouldn't disappear when the notification goes to the tray.

I'm pretty sure that the rationale behind this design is that if a user plugs something into the computer it's because he/she wants to do something with it. Therefore the notification doesn't go away until the user interacts with it. I think it's a pretty logical assumption, at least it makes total sense to me. So I'd say this isn't actually a bug. Designers would confirm this or not, though.

Well, I can thing of some use cases in which I plug a device in, or in which gnome think I plugged a device in but didn't, and in which I don't want to do anything with the said device or media:
1) Charging a smartphone, tablet or a portable media player using my computer's USB port.
2) Having an always connected external USB HDD backup drive (I see a notification about it being plugged in every time I login to my user account after boot)
3) Forgetting a DVD or a CD in the drive (you'll see the notification about it on every boot as well)

(In reply to comment #4)
> 2) Having an always connected external USB HDD backup drive (I see a
> notification about it being plugged in every time I login to my user account
> after boot)
> 3) Forgetting a DVD or a CD in the drive (you'll see the notification about it
> on every boot as well)

Maybe the real bug for both cases is that we should only show the notification for devices plugged in while the user is logged in?

I agree, but this still doesn't solve the problem of the first use case. The whole point of the GNOME 3 notification design is to be *less* distracting, and if I recall correctly, making autorun integrated into the shell instead of being in a window is to be less distracting... what we have now is as distracting as a window popping up.

The "don't show hotplug notifications on login" problem is bug 668771. But as I said there, I think the designers wanted this behavior (they may change their minds, though).

As for the "charging phone" case, I don't see how we can find a specific solution. If notifications went away after some delay, that would mitigate the problem.

More generally, I think it doesn't make sense to keep these notifications forever. The real problem IMO is that the actions are not available from the standard notification icon after the notification has gone away. If we found a way to make them available all the time, then we could safely hide the notification after some time. And that would be a nice improvement anyway, since you may need to select an action again, even if you used the notification the first time you needed to open the device.

Now that notifications remain visible until the user interacts with the device, we could possibly downgrade the priority of the hot-plug notifications.

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

There are two features of hotplug notifications:

1) They auto-expand
2) They do not get dismissed unless the user explicitly dismisses them.

I don't think either makes sense anymore with the current message tray behaviour. Do we want to remove them both?

Created attachment 223875 [details] [review]
messageTray: Don't auto-expand CRITICAL notifications

It's an annoyance, and with the new message tray design, it doesn't
make sense to do so.

Created attachment 223876 [details] [review]
messageTray: Don't keep CRITICAL notifications around forever

Since we keep notifications alive until the user has been guaranteed
to see them, we don't need to treat CRITICAL notifications as any
different in this regard.

Can I get a design OK on these, please?

Doesn't seem like a good idea to me to have critical battery warnings not expanding.

Would a better fix be to not make hotplug notifications critical? As far as I remember this was done for the stick-around case (as the notification contains more actions than the summary notification), not for expanding ...

I hardly see anything particular critical about "you have just plugged in something" ...

(In reply to comment #15)
> As far as I remember this was done for the stick-around case [...], not 
> for expanding ...

Of course the code says otherwise *sigh*

Created attachment 224649 [details] [review]
autorunManager: Do not mark the notification CRITICAL

There is nothing particularly critical about this notification, it
was only marked as such to get certain behavior like auto-expanding
and sticking-around to be acknowledged by the user (as it offers
more actions than the summary notification, so it is frustrating
when it goes away because it was missed).
As all notifications will now stay visible until we are sure the
users has seen them, the latter reasoning no longer applies.
Auto-expansion doesn't appear too important and may even be considered
annoying by users, so remove the CRITICAL hint now.

Review of attachment 224649 [details] [review]:

Makes sense.

Sigh. I did this a long time ago, and was rejected on sight. Still, can I get response on the "don't keep CRITICAL notifications around forever" patch?

(In reply to comment #14)
> Doesn't seem like a good idea to me to have critical battery warnings not
> expanding.

Aren't they at the full height by default?

(In reply to comment #19)
> Still, can I get
> response on the "don't keep CRITICAL notifications around forever" patch?

Ping on this? I'd like to get this annoyance in for 3.6.1.

Comment on attachment 223875 [details] [review]
messageTray: Don't auto-expand CRITICAL notifications

Rejecting as of comment #14.

Review of attachment 223876 [details] [review]:

Not sure about this one. There's some point in the reasoning, though I'm skeptical about changing behavior for all critical notifications because a specific notification is perceived less annoying when behaving more like a normal notification. It doesn't help that the notification in question is only marked "critical" to get some specific behavior, not because it is actually urgent (I really disagree with the notion that "urgency" is just an unfortunate hint name for tweaking notification behavior - IMHO it's the same reasoning as rants about attached modal dialogs breaking the minimal interaction with the parent window that was possible before for dialogs that should not be modal in the first place ...)

(In reply to comment #23)
> Review of attachment 223876 [details] [review]:
> 
> It doesn't help that the notification in question is only
> marked "critical" to get some specific behavior, not because it is actually
> urgent

See patches in #660609, then, which adds explicit API for "autoExpand", "shouldTimeout".

I don't think "shouldTimeout" should be a thing anymore, because we're guaranteed the user acknowledged it.

(In reply to comment #24)
> See patches in #660609, then, which adds explicit API for "autoExpand",
> "shouldTimeout".

That'll make it possible to make the autorun notification behave like critical notifications without abusing the urgency hint, but you'd end up with the exact same behavior this bug report calls "annoying" ...

You already removed the CRITICAL hint from autorun notifications. Do you think timing out is appropriate for other urgent notifications?

(In reply to comment #26)
> You already removed the CRITICAL hint from autorun notifications.

No. I'd like to, but not without designer approval.


>  Do you think timing out is appropriate for other urgent notifications?

I don't know. The current behavior has never bothered me for notifications that actually are critical (not sure I've ever seen one apart from the low-battery one, and my reaction to that is "OMG where's the plug" rather than "OMG how do I get rid of that bloody notification" :-)

Plus some people apparently are still capable of missing normal notifications[0] and we'd need to find a solution for battery notifications on the login screen[1] ...

[0] https://bugzilla.gnome.org/show_bug.cgi?id=641723#c141
[1] https://bugzilla.gnome.org/show_bug.cgi?id=684918#c5

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

Is this still relevant with the new design?

I guess? We still do hotplug notifications, and they are still marked as critical - though now there's a somewhat better justification for the behavior, considering that actions are only available in banner mode ...

Attachment 224649 [details] pushed as 31f1e9f - autorunManager: Do not mark the notification CRITICAL

Pushing this after some more IRC discussion with Carlos and Allan.