GNOME Bugzilla – Bug 709579
Magnifier: Focus tracking non responsive in Firefox
Last modified: 2021-07-05 10:45:06 UTC
I have only just got 3.10 on my desktop so I had a look at how the magnifier tracking is behaving itself in context,( which was nice! But...) I have noticed that although the caret browsing is being tracked for the magnifier the focus tracking does not seem to work in firefox. I will see how it fairs on other browsers as soon as I can. I have only just had a look so I have not yet had a chance to be thorough about the check but it seems very much like a bug to me. Anyone have any ideas why something like this might happen or suggestions for how to check properly? If the caret tracking was also a problem, I think it would be easier to figure this one out but I am not sure why the focus tracking only would not be working at the moment... To recreate: Open Firefox Turn on the magnifier Try and use the tab and/or navigation keys to somewhere out of view (e.g. the search bar or menu items) If the focused widget goes out of range of the view, then you will see what I am talking about. If not, please post some information if you think it will help. Thanks
Joanmarie and Mike Gorse were talking about something similar yesterday on IRC. Adding them on CC.
(In reply to comment #1) > Joanmarie and Mike Gorse were talking about something similar yesterday on IRC. > Adding them on CC. Thanks! But for what it's worth, that's an Orca bug and has nothing to do with this magnifier issue.
Could you try running gsettings set org.gnome.desktop.interface toolkit-accessibility true from a terminal, and see if it makes a difference?
(In reply to comment #3) > Could you try running > gsettings set org.gnome.desktop.interface toolkit-accessibility true > from a terminal, and see if it makes a difference? Confirmed. That is indeed necessary.
Ran $ gsettings set org.gnome.desktop.interface toolkit-accessibility true checked with $ gsettings get org.gnome.desktop.interface toolkit-accessibility confirming it was set to true still does not work. I need to double check the caret browsing because my caret is not being responsive. Will check this is not a separate issue with starting firefox after switching on the magnifier since I did that this time. Report back later.
ok restarting firefox and then putting the magnifier on seemed to get it recognised as an accessible application and Mike's recommendation has worked. I think it I could add some javascript to activate this gsetting when the magnifier is active and then file a separate bug about the firefox issue I mentioned above, since that is a different issue.
(In reply to comment #6) > I think it I could add some javascript to activate this gsetting when the > magnifier is active and then file a separate bug about the firefox issue I > mentioned above, since that is a different issue. The need to set the setting before start firefox is a known issue. This is because firefox is still a gtk+2 application, and will only initialize the gnome accessibility stuff if the setting is true when firefox starts.
Is there a bug for it?
Created attachment 257323 [details] [review] This patch is not working yet: advice sought. I think at-spi2-core might be a better place to activate the toolkit since it looks like that is done for the screen reader in here so I will move it. Unfortunately, I am not overly familiar with what is going on in the launcher.c file and do not really know if I am interpreting the logic correctly (I put some comments in). I was using this file to help get a better idea of what the desired outcomes are in the launcher https://github.com/linuxmint/Cinnamon/blob/master/src/cinnamon-a11y.c but obviously, there is less going on there so it only got me so far. I also used It would be useful to get some input/reviewing to help me make it work or otherwise, let me know if I ought to go back to plan A... What happens, is that the .desktop file activates the atspi launcher and if the a11y toolkit is set to true after that it will refresh using these two commands: AutostartCondition=GSETTINGS org.gnome.desktop.interface toolkit-accessibility X-GNOME-AutoRestart=true So, given that gnome.desktop.a11y.applications holds screen-reader-enabled and screen-magnifier enabled, I just tried to mimic the logic applied to get the screen-reader-enabled key and hoped that if the screen-magnifier-enabled key was true I could set the accessibility toolkit-accessibility toolkit from org.gnome.desktop.interface to true as well. At the moment changing the gsetting manually will cause an error to be thrown like this one: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe00031 (at-spi-dbu) (I think the last part is cut off) but I like the idea of doing it in here. It may be especially useful to have for when the screen-keyboard-enabled needs the toolkit too but open to suggestions. Thanks in advance.
Comment on attachment 257323 [details] [review] This patch is not working yet: advice sought. Thanks for the patch. I think that the over-all approach is fine. Comments in-line. >@@ -294,18 +298,15 @@ handle_a11y_enabled_change (A11yBusLauncher *app, gboolean enabled, > } > > static void >-handle_screen_reader_enabled_change (A11yBusLauncher *app, gboolean enabled, >+handle_app_enabled_change (A11yBusLauncher *app, gboolean enabled, There are several problems here. For one, you're trying to call this function whenever ScreenReaderEnabled or MagnifierEnabled are changed via D-Bus, and you're changing screen-reader-enabled and magnifier-enabled to the new value in gsettings. Ie, enabling the magnifier via D-BUs would automatically enable the screen reader, which we don't want. Why not simply write a handle_magnifier_enabled_change, modeling it after handle_screen_reader_enabled_change? But then we would need to ensure somewhere that turning off the magnifier does not have the side-effect of setting toolkit-accessibility to false if the screen reader is still enabled, and turning off the screen reader does not turn off accessibility if the magnifier is enabled (this could be done in handle_a11y_enabled_change or in the function(s) that call it). >@@ -564,8 +570,9 @@ gsettings_key_changed (GSettings *gsettings, const gchar *key, void *user_data) > > if (!strcmp (key, "toolkit-accessibility")) > handle_a11y_enabled_change (_global_app, new_val, FALSE); >- else if (!strcmp (key, "screen-reader-enabled")) >- handle_screen_reader_enabled_change (_global_app, new_val, FALSE); >+ // not sure about this >+ else if (!strcmp (key, "screen-reader-enabled") && (!strcmp (key, "screen-magnifier-enabled"))) >+ handle_app_enabled_change (_global_app, new_val, FALSE); That compare will always fail. Strcmp returns 0 if the strings are equal. You wanted || rather than &&, although I think it would be simpler to have a separate function to handle the magnifier being changed. >@@ -615,6 +626,11 @@ main (int argc, > ? g_settings_get_boolean (_global_app->a11y_schema, "screen-reader-enabled") > : FALSE; > } >+ if (!screen_magnifier_set) >+ _global_app->screen_reader_enabled = _global_app->a11y_schema I think you meant to set magnifier_enabled, rather than screen_reader_enabled.
Thanks for your help. I will try these changes in tha (In reply to comment #10) > (From update of attachment 257323 [details] [review]) > Thanks for the patch. I think that the over-all approach is fine. I will try the suggested changes in that case.
I suspect this should be moved to GNOME Shell. See https://bugzilla.gnome.org/show_bug.cgi?id=669192
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.