Project

General

Profile

Bug #14675

GNOME on-screen keyboard is broken without the X11 XTEST extensions

Added by anonym about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Accessibility
Target version:
Start date:
09/16/2017
Due date:
% Done:

100%

Feature Branch:
bugfix/14675-re-enable-X11-testing-extension
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

    Sep 16 08:05:27 amnesia caribou[10756]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
    Sep 16 08:07:57 amnesia org.gnome.Shell.desktop[9892]: Xlib:  extension "XTEST" missing on display ":1".

Can we make #14623 and #8281 to play nice with each other?


Related issues

Related to Tails - Feature #10263: Test that the on-screen keyboard works and its layout is correctly set Confirmed 09/26/2015
Related to Tails - Bug #14623: Tor Browser sandbox breakout via X11 testing extensions Confirmed 09/12/2017
Related to Tails - Feature #8281: Consider replacing Florence with GNOME's own on-screen keyboard Resolved 11/20/2014
Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 09/02/2017

Associated revisions

Revision 7a65275d (diff)
Added by intrigeri about 2 years ago

Re-enable the X11 testing extension: GNOME on-screen keyboard depends on it (refs: #14675).

Let's accept that our "sandbox" can be escaped via X11 and revert the changes
made in #14623: it's never been part of the threat model of this sandbox to
protect against such issues, and a11y + IBus allow basically the same kind of
breakouts anyway, so no big deal. Let's instead focus on Wayland (#12213).

This reverts commits 706e8ef83c7eb328d2e3bd633eb7aaea5c552fbb and 1f3367a450cf4b1ef8600b21d24d485810c25d7e.

Revision b465a3e3 (diff)
Added by anonym about 2 years ago

Add known issue for 3.2~rc1: GNOME screen keyboard broken.

Refs: #14675

Revision e38330e6
Added by anonym about 2 years ago

Merge remote-tracking branch 'origin/bugfix/14675-re-enable-X11-testing-extension' into testing

Fix-committed: #14675

Revision e09f7ae6 (diff)
Added by anonym about 2 years ago

Remove changelog entries for reverted feature.

Just so they are not left there by mistake when we release 3.2 final.

Refs: #14675

History

#1 Updated by yawning about 2 years ago

Can we make #14623 and #8281 to play nice with each other?

Do things the hard way and point Tor Browser at something that filters X11 calls.

#2 Updated by intrigeri about 2 years ago

>     Sep 16 08:05:27 amnesia caribou[10756]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
>     Sep 16 08:07:57 amnesia org.gnome.Shell.desktop[9892]: Xlib:  extension "XTEST" missing on display ":1".
> 

This log is about the on-screen keyboard while the title says screen reader. Are both affected?
Regardless, I'll handle this next week, somehow.

#3 Updated by anonym about 2 years ago

  • Subject changed from GNOME screen reader is broken without the X11 XTEST extensions to GNOME screen keyboard is broken without the X11 XTEST extensions

intrigeri wrote:

[...]

This log is about the on-screen keyboard while the title says screen reader. Are both affected?

I meant "reader", sorry!

#4 Updated by intrigeri about 2 years ago

  • Related to Feature #10263: Test that the on-screen keyboard works and its layout is correctly set added

#5 Updated by intrigeri about 2 years ago

  • Type of work changed from Research to Code

Sadly, at least on Stretch GNOME Shell delegates sending key events to Caribou, that itself uses XTEST to do so (while Florence can fallback to at-spi when XTEST is disabled, although apparently this can only be achieved by explicitly disabling XTEST support at compile time).

We've been very unlucky to break this in 3.2~rc1: had #14623 been ready for QA first, the breakage would have been noticed when reviewing #8281. It's tempting to raise the priority of #10263 that becomes a regression test. anonym, what do you think?

Long-term, GNOME is trying to get rid of Caribou, as Alan told me recently, and GNOME Shell 3.25.2's NEWS says Reduce dependency on Caribou [Carlos; #777342]. The corresponding support code landed in mutter, but on X11 the virtual input device still uses XTEST. We could ask GNOME to send at-spi events instead, but I doubt they'll invest dev time there as they are more focussed on Wayland these days, which has none of these problems anyway: there's no more XTEST of course, and the GNOME on-screen keyboard runs somewhat within the compositor so it can send key events directly via mutter/clutter.

Short-term, we have three options:

  1. go back to Florence i.e. revert #8281: this would make me sad given the amount of bugs #8281 fixed and the much more polished desktop UX we got out of it;
  2. accept that our "sandbox" can be escaped via X11 i.e. revert #14623: it's never been part of the threat model of this sandbox to protect against such issues, and a11y + IBus allow basically the same kind of breakouts anyway, so no big deal;
  3. as yawning suggests, "Do things the hard way and point Tor Browser at something that filters X11 calls": lots of work, rather outside of our skill set, unlikely to happen in time for 3.2

I don't think the third option is realistic (at least as far as 3.2 is concerned), and even if it was, it's questionable if it's worth investing so much effort into X11 instead of working on #12213. Between options 1 and 2, I much prefer option 2: the security impact is pretty slim (I mean, if Florence can do its job with at-spi and no XTEST, an attacker can do exactly the same as well, so why bother as long as we support a11y — which we do want to improve, not break) and the UX benefit is clear. I'll prepare a branch implementing option 2. Happy to hear other point of views, things I've missed etc. though :)

#6 Updated by intrigeri about 2 years ago

  • Related to Bug #14623: Tor Browser sandbox breakout via X11 testing extensions added

#7 Updated by intrigeri about 2 years ago

  • Related to Feature #8281: Consider replacing Florence with GNOME's own on-screen keyboard added

#8 Updated by intrigeri about 2 years ago

#9 Updated by intrigeri about 2 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/14675-re-enable-X11-testing-extension

#10 Updated by intrigeri about 2 years ago

  • Subject changed from GNOME screen keyboard is broken without the X11 XTEST extensions to GNOME on-screen keyboard is broken without the X11 XTEST extensions
  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

On an ISO built from this branch, I can use the on-screen keyboard in the overview and in gedit.

#11 Updated by anonym about 2 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Ready for QA to Dev Needed

To me option "2. accept that our "sandbox" can be escaped via X11 i.e. revert #14623" seems like a no-brainer: In the strictest sense, #14623 adds no defense since other vectors are still available, so it's not worth sacrificing anything for it. Reintroducing Florence would be a big sacrifice, hence #14623 should be reverted.

#12 Updated by intrigeri about 2 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Dev Needed to Ready for QA

(I'll assume you didn't reload the page before saving your metadata.)

#13 Updated by anonym about 2 years ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

#14 Updated by anonym about 2 years ago

  • Status changed from Fix committed to In Progress

#15 Updated by intrigeri about 2 years ago

  • Status changed from In Progress to Fix committed

(Referencing an issue with "refs:" makes it "In progress" again. I doubt that's what you meant to do.)

#16 Updated by pablonatalino about 2 years ago

intrigeri wrote:

Sadly, at least on Stretch GNOME Shell delegates sending key events to Caribou, that itself uses XTEST to do so (while Florence can fallback to at-spi when XTEST is disabled, although apparently this can only be achieved by explicitly disabling XTEST support at compile time).

We've been very unlucky to break this in 3.2~rc1: had #14623 been ready for QA first, the breakage would have been noticed when reviewing #8281. It's tempting to raise the priority of #10263 that becomes a regression test. anonym, what do you think?

Long-term, GNOME is trying to get rid of Caribou, as Alan told me recently, and GNOME Shell 3.25.2's NEWS says Reduce dependency on Caribou [Carlos; #777342]. The corresponding support code landed in mutter, but on X11 the virtual input device still uses XTEST. We could ask GNOME to send at-spi events instead, but I doubt they'll invest dev time there as they are more focussed on Wayland these days, which has none of these problems anyway: there's no more XTEST of course, and the GNOME on-screen keyboard runs somewhat within the compositor so it can send key events directly via mutter/clutter.

Short-term, we have three options:

  1. go back to Florence i.e. revert #8281: this would make me sad given the amount of bugs #8281 fixed and the much more polished desktop UX we got out of it;
  2. accept that our "sandbox" can be escaped via X11 i.e. revert #14623: it's never been part of the threat model of this sandbox to protect against such issues, and a11y + IBus allow basically the same kind of breakouts anyway, so no big deal;
  3. as yawning suggests, "Do things the hard way and point Tor Browser at something that filters X11 calls": lots of work, rather outside of our skill set, unlikely to happen in time for 3.2

I don't think the third option is realistic (at least as far as 3.2 is concerned), and even if it was, it's questionable if it's worth investing so much effort into X11 instead of working on #12213. Between options 1 and 2, I much prefer option 2: the security impact is pretty slim (I mean, if Florence can do its job with at-spi and no XTEST, an attacker can do exactly the same as well, so why bother as long as we support a11y — which we do want to improve, not break) and the UX benefit is clear. I'll prepare a branch implementing option 2. Happy to hear other point of views, things I've missed etc. though :)

I can't use very well riseup, let me know if you've done anything wrong by trying to comment.

But I think the important points for accessibility are:
1. The user's ability to keep the keyboard visible at any time not only in programs and specific times.
2. Ability to place and move the keyboard at any location on the screen as in Florence using a button.
3. Ability to adjust the keyboard size.
4. (Dispensable point but I think important) a beautiful keyboard not with old-looking buttons.

As a user I prefer option 1. (I'm sorry for your sadness Intrigeri)

Follow my personal reasons for use. I few times use the tails on a computer 2 in 1 (HP Pavillion), ie sometimes I double the screen and use the tails as a "tablet", something that brings a bad experience But that worked since using with mouse and touch, and then with the end of the keyboard Florence I can not have any autonomy, for example I had before, trying to enter an address in the browser or a simple search, did this using the virtual keyboard (Florence) and the mouse , and just now I can't do it anymore because the keyboard doesn't show up at all the locations I want, it appeared to me just in the text editors, well another change and now I can no longer put the keyboard in place of the screen where I want , it (when it pops up) just gets stuck down by occupying the entire screen at the bottom, in the spaces of the sidelines totally useless and paralyzed, well the improvement was design, because on the keyboard Florence, was in a very "old" way, anyway, the functionality of having the virtual keyboard in Time and place of the screen I want was important, because so I could use, although in a rustic way to combine Florence-mouse-touch of the tails, the keyboard property and not always available does not seem to be accessible.

#17 Updated by intrigeri almost 2 years ago

I can't use very well riseup, let me know if you've done anything wrong by trying to comment.

Thanks a lot for your feedback! Indeed, your comment is pretty much off-topic on this ticket, but that's fine: I vastly prefer feedback anywhere off-topic than no feedback at all :)
I've moved this discussion to #14713 where I'm going to reply right now.

#18 Updated by anonym almost 2 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF