GNOME Bugzilla – Bug 683301
stage: Normalize key focus setting
Last modified: 2012-09-07 14:23:22 UTC
See patch. This fixes the "flashing" of the message tray. What happens: 1) After a pushModal/popModal pair (Alt-Tab, run dialog), the key focus is set to the stage, because we save what get_key_focus returns to us. 2) GrabHelper listens to know when the key focus has changed. It does this by listening to notify::key-focus. If the new key focus is outside the actor that was grabbed, it will drop the grab. 3) When we hover over a notification when coming from a window, the activate signal is sent out on the stage, which will cause a notify::key-focus, except if there's no focused actor (because the stage is focused). 4) GrabHelper drops the grab, and then re-grabs because the notification has not expired yet. This is easily fixable by preventing step 3, by treating the stage as the same as NULL.
Created attachment 223384 [details] [review] stage: Normalize key focus setting We often mean that when key_focus == NULL, it's assumed to be on the stage, and clutter_stage_get_key_focus() reflects this. We also do a lot of check around the lines of key_focus == NULL instead of also checking for the stage, so make sure to normalize it so that explicitly grabbing the stage's key focus will not change our behaviour.
Created attachment 223385 [details] [review] stage: Normalize key focus setting We often mean that when key_focus == NULL, it's assumed to be on the stage, and clutter_stage_get_key_focus() reflects this. We also do a lot of check around the lines of key_focus == NULL instead of also checking for the stage, so make sure to normalize it so that explicitly grabbing the stage's key focus will not change our behaviour. Put the normalizing above the equality check, for a better chance at a short circuit.
Review of attachment 223385 [details] [review]: looks good to me.
Attachment 223385 [details] pushed as 3398f3a - stage: Normalize key focus setting
*** Bug 682478 has been marked as a duplicate of this bug. ***