GNOME Bugzilla – Bug 693975
More fixes for the GrabHelper
Last modified: 2013-02-16 18:34:19 UTC
drago01 spotted these while working on a message tray context menu.
Created attachment 236389 [details] [review] grabHelper: Use a mode: js header This brings us into consistency with the rest of the modelines
Created attachment 236390 [details] [review] grabHelper: Correct typo preventing focus-window-changed disconnect While debugging, I found that the signal to focus-window-changed was never getting disconnected, making a call to ungrab every time the focus window changed, even if there were no focus grabs anymore.
Created attachment 236391 [details] [review] grabHelper: Track the grab before trying to set key focus If we don't this for a nested grabFocus grab, the notify::key-focus will be called, not think that the new key focus is part of the grab, and cancel the full grab. This leaves the grab helper in an inconsistent and confused state, as the grab is pushed onto the grab stack after.
Created attachment 236392 [details] [review] grabHelper: Ignore key focus changes when ungrabbing Calling onUngrab() may change key focus, either directly or indirectly (e.g. hiding the actor). Such key focus changes would cause an extra actor to be ungrabbed, so make sure to ignore such focus changes while we're ungrabbing.
Review of attachment 236389 [details] [review]: OK.
Review of attachment 236390 [details] [review]: Good catch.
Review of attachment 236391 [details] [review]: Makes sense.
Review of attachment 236392 [details] [review]: Makes sense and seems to fix the bug I saw while working on the menu.
Attachment 236389 [details] pushed as fe2c201 - grabHelper: Use a mode: js header Attachment 236390 [details] pushed as 5f995c6 - grabHelper: Correct typo preventing focus-window-changed disconnect Attachment 236391 [details] pushed as 180000a - grabHelper: Track the grab before trying to set key focus Attachment 236392 [details] pushed as 3628c81 - grabHelper: Ignore key focus changes when ungrabbing