Seems like it would have to be a graphics driver bug.

Not sure how, but perhaps. Jon reported the same/similar behaviour on IRC.

Using NVIDIA here, not sure what he's on.

I've seen a few times on i965 here.  Alt+f2 also makes it work again.  Can't reproduce with xset dpms force off though.

I can reproduce this here on F13 with:
pkill rhythmbox; gnome-screensaver-command --lock; sleep 3; (rhythmbox &); sleep 1; rhythmbox-client --notify

When I use LG to make the hot corner rectangle any larger than 1x1 (even 2x1) I can no longer reproduce the problem.

Another effect besides not being hot is that that pixel is not responsive to clicks.

try using the inspector? Alt-F2, lg, click the dropper icon, then go to the hot corner and see if there's some non-hotspot actor blocking the hotspot?. You can also use mousewheel-up to dig down the stack (eg, to verify that the hotspot is underneath whatever actor is on top).

(In reply to comment #4)
> I can reproduce this here on F13 with:
> pkill rhythmbox; gnome-screensaver-command --lock; sleep 3; (rhythmbox &);
> sleep 1; rhythmbox-client --notify
> 

Can reproduce using this on my end as well.

(In reply to comment #6)
> try using the inspector? Alt-F2, lg, click the dropper icon, then go to the hot
> corner and see if there's some non-hotspot actor blocking the hotspot?. You can
> also use mousewheel-up to dig down the stack (eg, to verify that the hotspot is
> underneath whatever actor is on top).

No, because as mentioned alt-f2 makes the problem go away.  So instead I tried adding a one sec timeout to get_actor_at_pos(0,0) and didn't see anything unusual unfortunately.

Ok so it took Owen an impressive 10 seconds to identify this as due to:
63f206613564297867d0294a6e1cce8f5ca25448

To explain more, when the screen is locked, we hide the shell chrome. So newly appearing status icons never get painted at all. That means that the ShellGtkEmbed code that allocates the GTK+ widget on paint doesn't run and the status icon X window ends up left as 0x0+1+1.

So we need to either unmap that window until we first allocate it, or maybe allocate it preemptively the first time the Clutter actor gets allocated.

Created attachment 177761 [details] [review]
messageTray: use alignment rather than gravity to position the summary

Actors in clutter are supposed to be re-allocated with
Clutter.AllocationFlags.ABSOLUTE_ORIGIN_CHANGED if they move relative
to the screen, even if they don't move relative to their parent.
Currently this does not work correctly for actors inside containers
with non-northwest gravity. This is probably a fixable bug, but
gravity has messed up other things in the past too, so let's just not
use it.

This change ensures that summary trayicons are re-allocated when the
summary animates, and is part of the fix for

Created attachment 177762 [details] [review]
ShellGtkEmbed: revert to old actor/window position-syncing code

Synchronizing the actor and window position on paint resulted in lots
of syncing, and also resulted in the window mistakenly being left at
0,0 if the actor wasn't visible when the window first mapped.

Revert back to the old way of doing it, by tying into
clutter_actor_allocate, which was only failing before because of a bug
elsewhere.

filed http://bugzilla.clutter-project.org/show_bug.cgi?id=2509

Review of attachment 177761 [details] [review]:

Looks reasonable, works in testing

Review of attachment 177762 [details] [review]:

Looks like a correct revert

Attachment 177761 [details] pushed as 4c4a703 - messageTray: use alignment rather than gravity to position the summary
Attachment 177762 [details] pushed as 84bac44 - ShellGtkEmbed: revert to old actor/window position-syncing code