GNOME Bugzilla – Bug 776854
Unwanted 'window:activate'/'deactivate' pairs when triggering WM global shortcuts
Last modified: 2021-07-05 10:45:13 UTC
Created attachment 342816 [details] [review] Event log when triggering the "main menu" global WM shortcut (Alt+F1) This looks similar to https://bugzilla.gnome.org/show_bug.cgi?id=108664 to me. I'm not totally sure, but I guess that the global WM shortcuts use an X grab at some level, and lead to the extra deactivate/activate pair. In any case, triggering this kind of keybinding (like Alt+F1 to open the main MATE menu, but any other do the same), be it with Metacity, Marco or Compiz as WM, there is an extra pair of deactivate/activate on the current window. This leads tools like Orca to present the window again, as they see what looks like a legitimate window switch. Attached is a log of all events (window, object, focus, mouse) happening when triggering the MATE main menu with Alt+F1 under Metacity. The interesting part is: > --- 11:01:05 > window:deactivate(0, 0, Document 1 sans titre - gedit) > source: [frame | Document 1 sans titre - gedit] > host_application: [application | gedit] > --- 11:01:05 > object:state-changed:focused(0, 0, 0) > source: [toggle button | Changer la page du panneau latéral] > host_application: [application | gedit] > --- 11:01:05 > object:state-changed:active(0, 0, 0) > source: [frame | Document 1 sans titre - gedit] > host_application: [application | gedit] > --- 11:01:05 > window:activate(0, 0, Document 1 sans titre - gedit) > source: [frame | Document 1 sans titre - gedit] > host_application: [application | gedit] Sorry for the French in the apps here, but I believe the useful info are in English just fine.
Created attachment 342817 [details] Small script to log events
(In reply to Colomban Wendling from comment #0) > In any case, triggering this kind of keybinding (like Alt+F1 to open the > main MATE menu, but any other do the same), be it with Metacity, Marco or > Compiz as WM, there is an extra pair of deactivate/activate on the current > window. Could you check if you have the same problem on gnome-shell under X?
(In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #2) > Could you check if you have the same problem on gnome-shell under X? Yes I do (tested under Debain stable's gnome-shell 3.14). If I setup a custom keybinding triggering a non-GUI command (I tried with `df /`) and bind it to something like `<Ctrl><Alt>T`, I get the window:deactivate/activate pair I'm talking about. You can also see it trying a non-existing `<Super>`-based keybinding like say, `<Super>X`: you get a deactivate event on pressing `<Super>`, and an activate one hitting `X` (which, as it's unbound, results in a plain `x` in the terminal).
(In reply to Colomban Wendling from comment #3) > (In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #2) > > Could you check if you have the same problem on gnome-shell under X? > > Yes I do (tested under Debain stable's gnome-shell 3.14). > > If I setup a custom keybinding triggering a non-GUI command (I tried with > `df /`) and bind it to something like `<Ctrl><Alt>T`, I get the > window:deactivate/activate pair I'm talking about. > > You can also see it trying a non-existing `<Super>`-based keybinding like > say, `<Super>X`: you get a deactivate event on pressing `<Super>`, and an > activate one hitting `X` (which, as it's unbound, results in a plain `x` in > the terminal). Thanks for confirming. I have been thinking a little about this. So here some quick thoughts: 1. Those events are emitted because there was a window change. You have a guess here: > I'm not totally sure, but I guess that the global WM shortcuts use an X grab at some level, and lead to the extra deactivate/activate pair. So internally there is a window change, even if it is a temporal X grab. I don't think that at-spi could know if they are spurious or not. And that leads to the following point. 2. This is not exactly an at-spi core/registry issue but and implementation of the interfaces. at-spi core/registry is just forwarding what the implementors (atk on the WM, etc) are emitting. In fact, most of the solution for the bug you point (this [2]), is solved on metacity and gtk accessibility implementation. You can find an easier to read but still similar bug here [1] Summarizing, with the current info, I don't see this an at-spi bug. So the way to solve this would be know for sure what is causing those extra emissions, and try to solve it on the emitter side. If that fails, perhaps add a new Orca heuristics, although probably that is unwise, taking into account that the window activate/deactivate heuristics on Orca are already complex enough. [1] https://bugzilla.gnome.org/show_bug.cgi?id=746670 [2] https://bugzilla.gnome.org/show_bug.cgi?id=108664
(In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #4) > 1. Those events are emitted because there was a window change. You have a > guess here: > > > I'm not totally sure, but I guess that the global WM shortcuts use an X grab at some level, and lead to the extra deactivate/activate pair. > > So internally there is a window change, even if it is a temporal X grab. Well, technically it seems that it's not really a window change per se, but yes that the active window gets an X FocusOut event when the grab starts, and a FocusIn one when it ends (if I trust my findings): the window is still active, but not receiving input, thus X emitting those pairs or events. But yeah I guess this makes it perfectly understandable that the AT-SPI events get emitted. I now I found the great (yet sad, as it was 2007) thread about this at the Metacity level: https://mail.gnome.org/archives/wm-spec-list/2007-May/msg00000.html. Other links from https://stackoverflow.com/questions/15270420/why-xgrabkey-generates-extra-focus-out-and-focus-in-events might be possibly interesting also. > I don't think that at-spi could know if they are spurious or not. And > that leads to the following point. I guess that if events are queued before getting emitted, it would be fairly easy to recognize: it's a window:deactivate/object:state-changed:focused(0)/object:state-changed:active(0)/window:activate/object:state-changed:focused(1)/object:state-changed:active(1) chain, all on the same app (and all but the focused on the same object) -- and all that fairly quickly. But I can understand that filtering like that is at least not so pretty. > 2. This is not exactly an at-spi core/registry issue but and implementation > of the interfaces. at-spi core/registry is just forwarding what the > implementors (atk on the WM, etc) are emitting. In fact, most of the > solution for the bug you point (this [2]), is solved on metacity and gtk > accessibility implementation. Has it? Good :) > You can find an easier to read but still similar bug here [1] Well, it's basically the exact contrary: missing event. So maybe I miss some possibilities, but it seems easier to generate an event than remove an existing one. > Summarizing, with the current info, I don't see this an at-spi bug. > So the way to solve this would be know for sure what is causing those extra > emissions, and try to solve it on the emitter side. No indeed it's most probably not really an at-spi *bug*. The problem is that I spent a fair amount of time seeing what I can do where, and it seems impossible not to emit the FocusOut/FocusIn pair when a X key grab happens, and impossible to implement global shortcuts without it leading to a grab -- at least short of rewriting the whole thing to use maybe XI2 raw events or something, not sure about that. The reason I then reported it here is that it seemed like the most feasible and least absurd level at which this could be worked around. But now I read the thread linked above, maybe the actual emitter of the window:deactivate event could do something, even though it sounds tricky to do it right. Do you know how window:deactivate is sent? I'm guessing it would be GTK/GAIL, but I'm not sure what leads to emitting that specific event. I'll try and find it out but if you know it could possibly get me there faster :) > If that fails, perhaps > add a new Orca heuristics, although probably that is unwise, taking into > account that the window activate/deactivate heuristics on Orca are already > complex enough. Yeah I though about it, and for the specific case of https://bugzilla.gnome.org/show_bug.cgi?id=776862 it could somehow work, but as you suggest Orca seems to already have a complex enough set of heuristics for adding more and more layers to it to feel right.
(In reply to Colomban Wendling from comment #5) > (In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #4) > > 1. Those events are emitted because there was a window change. You have a > > guess here: > > > > > I'm not totally sure, but I guess that the global WM shortcuts use an X grab at some level, and lead to the extra deactivate/activate pair. > > > > So internally there is a window change, even if it is a temporal X grab. > > Well, technically it seems that it's not really a window change per se, but > yes that the active window gets an X FocusOut event when the grab starts, > and a FocusIn one when it ends (if I trust my findings): the window is still > active, but not receiving input, thus X emitting those pairs or events. > But yeah I guess this makes it perfectly understandable that the AT-SPI > events get emitted. > > I now I found the great (yet sad, as it was 2007) thread about this at the > Metacity level: > https://mail.gnome.org/archives/wm-spec-list/2007-May/msg00000.html. Interesting reading. This email from the thread gives some hints: https://mail.gnome.org/archives/wm-spec-list/2007-May/msg00002.html > Other > links from > https://stackoverflow.com/questions/15270420/why-xgrabkey-generates-extra- > focus-out-and-focus-in-events might be possibly interesting also. > > > I don't think that at-spi could know if they are spurious or not. And > > that leads to the following point. > > I guess that if events are queued before getting emitted, it would be fairly > easy to recognize: it's a > window:deactivate/object:state-changed:focused(0)/object:state-changed: > active(0)/window:activate/object:state-changed:focused(1)/object:state- > changed:active(1) chain, all on the same app (and all but the focused on the > same object) -- and all that fairly quickly. > > But I can understand that filtering like that is at least not so pretty. Well, my main concern is not about being pretty or not. There are plenty of not pretty things on at-spi or on atk implementors. My main concern is about implementing a general filtering on at-spi based on a heuristic like the one you mention, and find later that is not working properly on some use cases. So not saying that we shouldn't. I didn't look deep enough to that. Just saying that it is likely that the implementor knows more about the issue, as in other cases in the past. > > > 2. This is not exactly an at-spi core/registry issue but and implementation > > of the interfaces. at-spi core/registry is just forwarding what the > > implementors (atk on the WM, etc) are emitting. In fact, most of the > > solution for the bug you point (this [2]), is solved on metacity and gtk > > accessibility implementation. > > Has it? Good :) > > > You can find an easier to read but still similar bug here [1] > > Well, it's basically the exact contrary: missing event. So maybe I miss > some possibilities, but it seems easier to generate an event than remove an > existing one. Yes, I explained myself properly. The case is the contrary. The case is similar in the sense that it was related to window events, and was solved on the implementor, not on at-spi. > > Summarizing, with the current info, I don't see this an at-spi bug. > > So the way to solve this would be know for sure what is causing those extra > > emissions, and try to solve it on the emitter side. > > No indeed it's most probably not really an at-spi *bug*. The problem is > that I spent a fair amount of time seeing what I can do where, and it seems > impossible not to emit the FocusOut/FocusIn pair when a X key grab happens, > and impossible to implement global shortcuts without it leading to a grab -- > at least short of rewriting the whole thing to use maybe XI2 raw events or > something, not sure about that. > > The reason I then reported it here is that it seemed like the most feasible > and least absurd level at which this could be worked around. > > But now I read the thread linked above, maybe the actual emitter of the > window:deactivate event could do something, even though it sounds tricky to > do it right. > Do you know how window:deactivate is sent? I'm guessing it would be > GTK/GAIL, but I'm not sure what leads to emitting that specific event. I'll > try and find it out but if you know it could possibly get me there faster :) Don't know for sure. GTK is a good guess, but AFAIR, metacity also had some ATK code, so it would be good to take a look there too. > > If that fails, perhaps > > add a new Orca heuristics, although probably that is unwise, taking into > > account that the window activate/deactivate heuristics on Orca are already > > complex enough. > > Yeah I though about it, and for the specific case of > https://bugzilla.gnome.org/show_bug.cgi?id=776862 it could somehow work, but > as you suggest Orca seems to already have a complex enough set of heuristics > for adding more and more layers to it to feel right.
(In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #6) > (In reply to Colomban Wendling from comment #5) > > […] > > > > I now I found the great (yet sad, as it was 2007) thread about this at the > > Metacity level: > > https://mail.gnome.org/archives/wm-spec-list/2007-May/msg00000.html. > > Interesting reading. This email from the thread gives some hints: > https://mail.gnome.org/archives/wm-spec-list/2007-May/msg00002.html Yes, but it's not very clear in the end what a client should do. They mention "it would be good to have a new thing", but that stopped here it seems… Anyway, I asked on GTK list CCing GNOME a11y to see what they think would be appropriate: https://mail.gnome.org/archives/gtk-devel-list/2017-January/msg00012.html > Don't know for sure. GTK is a good guess, but AFAIR, metacity also had some > ATK code, so it would be good to take a look there too. Found it in GTK/GAIL, that part played out fine :)
Hello, I have reported the issue to gtk+ https://gitlab.gnome.org/GNOME/gtk/issues/85 I guess we should mark the at-spi report invalid? Samuel
If it has only to be fixed on GTK side, I agree with you Samuel. We should close this bug. Best regards.
Moving open tickets in at-spi2' "registry" Bugzilla component to "at-spi2-core" as it has a subdir called "registryd".
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/ Thank you for your understanding and your help.