On every startup Onboard asks for enabling accessibility

Bug #1227173 reported by Till Kamppeter on 2013-09-18
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Onboard
Undecided
Unassigned
gnome-control-center (Ubuntu)
High
Unassigned
gnome-settings-daemon (Ubuntu)
High
Unassigned
onboard (Ubuntu)
High
Luke Yelavich

Bug Description

I have a Lenovo Thinkpad Twist convertible ultrabook. The tablet mode (touchscreen-only operation, keyboard folded away) gets continuously working better.

I use Onboard as on-screen keyboard to do text input on my convertible in tablet mode (see bug 1210823). This works very well but there is an awkwardness on startup. Every time when Onboard is started (in my case by the laptop/tablet mode switcher script) a dialog pops up which reads:

----------
Enabling auto-show requires Gnome Accessibility

Onboard can turn on accessibility now, however it is recommended that you log out and back in for it to reach its full potential.

Enable accessibility now?
----------

It gives me a "No" and a "Yes" button to answer. I click "Yes" to get the keyboard. Then the keyboard works correctly for the rest of the session (I have set it to show when I am in a text field and to hide otherwise). It does not ask when I switch to laptop mode (which kills Onboard) and back to tablet mode (restarts Onboard), but If I log out and log in again, it asks again.

So it seems that it is not saved to be kept over sessions that I have answered "Yes" to activate accessibility mode. So I am not sure whether really Onboard is the culprit or perhaps gnome-control-center or gnome-settings-daemon.

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → High
Changed in gnome-control-center (Ubuntu):
importance: Undecided → High
Changed in gnome-settings-daemon (Ubuntu):
milestone: none → ubuntu-13.10
Changed in gnome-control-center (Ubuntu):
milestone: none → ubuntu-13.10
marmuta (marmuta) wrote :

Hi Till, how do you start Onboard? Is it auto-started by the Universal Access setting in gnome-control-center?
gsettings get org.gnome.desktop.a11y.applications screen-keyboard-enabled

Apparently if neither screen-keyboard nor screen-reader are enabled, gnome-settings-daemon may turn a11y off right after login:
(gnome-settings-daemon_:2229): a11y-settings-plugin-DEBUG: screen reader or OSK enablement changed
(gnome-settings-daemon_:2229): a11y-settings-plugin-DEBUG: Disabling toolkit-accessibility, screen reader and OSK disabled

This isn't good for a manually started Onboard, since we need a11y for both auto-show and word suggestions. Hence the dialog asking to turn toolkit-accessibility back on.

Till Kamppeter (till-kamppeter) wrote :

As I use Onboard as stabdard way to do text input in tablet (=touch-screen-only) mode the onscreen keyboard is not an accessibility feature but a facility for all users. This means that it should not require any special accessibility settings.

I start it with a script which gets triggered by the ACPI signal for the transition from laptop mode into tablet mode and kill it also by a script on the ACPI signal of switching from tablet mode to laptop mode.

See the ACPI config files, scripts, and how this all works in bug 1210823.

The command to start Onboard used by the script is

sudo -iu $user onboard &

$user is the user logged in to the desktop and also the variables DISPLAY and XAUTHORITY are set properly, so that the script which is running as root can open the keyboard on the user's display and running as the user.

I have configured Onboard to use auto-hide mode via the GUI configuration panel of Onboard.

Francesco Fumanti (frafu) wrote :

As marmuta said above, the auto-show (auto-hide) needs the accessibility framework to be enabled. In fact, it is the accessibility framework that informs onboard about when to appear and hide. Thus, it is not possible to use the auto-show feature without enabling the accessibility framework.

We might perhaps add an option "Do not ask again" to the dialog about enabling the accessibility framework. And if the user enables it, each time Onboard starts up, it would automatically enable the accessibility framework, unless the user enabled the new option and clicked to not enable the accessibility framework.

For Till's needs, a corresponding gsettings key without a GUI might even be sufficient.

Till Kamppeter (till-kamppeter) wrote :

So for tablet mode one could perhaps activate auto-hide and accessibility mode via gsettings, so that the question does not appear at all, as users would not know what this is good for.

marmuta (marmuta) wrote :

We could set 'toolkit-accessibility' silently in Onboard's startup, but that should be the last option. I'd prefer not to fight with gnome-settings-daemon over that key. It would still be an incomplete solution, since 'screen-keyboard-enabled' can be reset any time afterwards, taking down a11y for new processes with it.

Setting 'screen-keyboard-enabled'=true in your script when entering tablet mode would get rid of the dialog, but some processes started before tablet mode might still be invisible to Onboard, firefox in particular. You'd have to restart them after switching to get auto-show and word suggestions working.

The only real solution I see is keeping 'toolkit-accessibility' enabled at all times, i.e. not letting g-s-d turn it off. Either by patching gsd-a11y-settings-manager.c, or by deactivating the a11y-settings plugin.

Try this:
gsettings set org.gnome.settings-daemon.plugins.a11y-settings active false

You have to do this only once, and looking through the source, there seems little harm for your custom setup in disabling the plugin.

Till Kamppeter (till-kamppeter) wrote :

This does not work at all, the setting change is silently rejected:

till@till-twist:~$ gsettings get org.gnome.settings-daemon.plugins.a11y-settings active
true
till@till-twist:~$ gsettings set org.gnome.settings-daemon.plugins.a11y-settings active false
till@till-twist:~$ gsettings get org.gnome.settings-daemon.plugins.a11y-settings active
false
till@till-twist:~$

And due to this I still get the dialog.

Till Kamppeter (till-kamppeter) wrote :

Problem was that I have entered the gsettings commands SSHed in from another machine. Now I have tried again on the machine's own screen and the switching works, but now I cannot log in any more. .xsession-errors contains

Script for cjkv started at run_im.
Script for default started at run_im.
init: gnome-settings-daemon main process (2964) terminated with status 1
init: gnome-session main process (2971) terminated with status 1
init: unity-panel-service main process (2973) terminated with status 1

Till Kamppeter (till-kamppeter) wrote :

Now, after doing it again and again, it started to work.

marmuta (marmuta) wrote :

OK, thank you, it is indeed g-s-d then. I've opened an upstream bug report here:
https://bugzilla.gnome.org/show_bug.cgi?id=708506

I'll mark the Onboard task as "incomplete" until we know more about the prospect for g-s-d changes. Feel free to change this.

Changed in gnome-control-center (Ubuntu):
status: New → Invalid
Changed in onboard (Ubuntu):
status: New → Incomplete
Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed

I have made another important observation:

If I run

gsettings set org.gnome.settings-daemon.plugins.a11y-settings active false

the dialog asking to activate accessibility goes away, but the login very often fails, I have to enter my password in lightdm 5 or 6 times until succeeding a login.

After running

gsettings set org.gnome.settings-daemon.plugins.a11y-settings active true

the logins succed again.

Failed logins give an .xsession-errors like this

Script for cjkv started at run_im.
Script for default started at run_im.
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd respawning too fast, stopped
init: gnome-settings-daemon main process (5110) terminated with status 1
init: gnome-session main process (5128) terminated with status 1
init: unity-panel-service main process (5137) terminated with status 1
init: logrotate pre-start process (5055) killed by TERM signal

Succeeded logins give the following .xsession-errors:

Script for cjkv started at run_im.
Script for default started at run_im.
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd respawning too fast, stopped

For the at-spi2 messages I have also reported bug 1228567.

marmuta (marmuta) wrote :

I can't reproduce the login problems here, no good idea why that happens for you. I must be missing something, but the plugin really doesn't seem to do a lot.

Is there anything in the other log files?
sudo grep -r at-spi2-registryd /var/log/*

Nothing found in the logs.

I had also further login failures later, so probably the problems are independent.

I have done "gsettings set org.gnome.settings-daemon.plugins.a11y-settings active false" currently and I have checked that it is actually set this way via "gsettings get org.gnome.settings-daemon.plugins.a11y-settings active", but when starting Onboard after login the dialog asking whether I want to use a11y mode still appears.

I think we should simply stay in a11y mode all the time.

marmuta (marmuta) wrote :

You might see the dialog one more time after turning the plugin off. Does it still show after repeated logins?

I have now tried more three times and the dialog still appears.

"gsettings get org.gnome.settings-daemon.plugins.a11y-settings active" still gives "false".

Now I have rebooted due to a Bluetooth problem and after rebooting after every login starting Onboard does not pop up the dialog any more. Seems that the reboot has fixed this.

I get a black screen for 5-10 seconds every time I logon after upgrading to 13.10. I have this in ~/.xsession-errors

thnov@thnov-desktop:~$ cat .xsession-errors
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd respawning too fast, stopped

Regular desktop PC.

Changed in onboard (Ubuntu):
milestone: ubuntu-13.10 → saucy-updates
Changed in gnome-settings-daemon (Ubuntu):
milestone: ubuntu-13.10 → saucy-updates
Sebastien Bacher (seb128) wrote :

Luke, could you have a look to this bug and see if that's something we should work on

Changed in onboard (Ubuntu):
assignee: nobody → Luke Yelavich (themuso)
ergo-proxy (ergo-proxy) wrote :

I observe the same behaviour as in comment #19.

Clean installation 13.10x64, up to date.

cat .xsession-errors
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: at-spi2-registryd uruchamia się ponownie zbyt szybko, zatrzymano

and .xsession-errors.oldcat .xsession-errors.old
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: Proces at-spi2-registryd main został zakończony, ponowne uruchamianie
init: at-spi2-registryd uruchamia się ponownie zbyt szybko, zatrzymano
init: Proces gnome-settings-daemon main (1834) został zakończony ze stanem 1
init: Proces gnome-session main (1910) został zakończony ze stanem 1
init: Proces unity-panel-service main (1922) został zakończony ze stanem 1

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.