Bug #14675

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

Added by anonym 2017-09-16 18:03:13 . Updated 2017-09-28 18:49:06 .

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

100%

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

Starter:
Affected tool:
Deliverable for:

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 Bug #14623 and Feature #8281 to play nice with each other?

Subtasks

Related issues

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

History

#1 Updated by yawning 2017-09-16 19:55:32

> Can we make Bug #14623 and Feature #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 2017-09-17 07:50:24

>

>     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 2017-09-17 12:54:29

  • 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 2017-09-18 08:04:25

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

#5 Updated by intrigeri 2017-09-18 08:15:05

  • 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 Bug #14623 been ready for QA first, the breakage would have been noticed when reviewing Feature #8281. It’s tempting to raise the priority of Feature #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 Feature #8281: this would make me sad given the amount of bugs Feature #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 Bug #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 Feature #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 2017-09-18 08:15:23

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

#7 Updated by intrigeri 2017-09-18 08:22:40

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

#8 Updated by intrigeri 2017-09-18 08:25:19

#9 Updated by intrigeri 2017-09-18 08:27:00

  • 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 2017-09-18 09:43:03

  • 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 2017-09-18 10:50:35

  • 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 Bug #14623" seems like a no-brainer: In the strictest sense, Bug #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 Bug #14623 should be reverted.

#12 Updated by intrigeri 2017-09-18 11:22:17

  • 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 2017-09-18 17:23:27

  • 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 2017-09-18 17:39:31

  • Status changed from Fix committed to In Progress

Applied in changeset commit:e09f7ae65400a1854f6e12fe493766b23fc33cfe.

#15 Updated by intrigeri 2017-09-18 18:12:08

  • 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 2017-09-22 12:44:07

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 Bug #14623 been ready for QA first, the breakage would have been noticed when reviewing Feature #8281. It’s tempting to raise the priority of Feature #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:
>
> # go back to Florence i.e. revert Feature #8281: this would make me sad given the amount of bugs Feature #8281 fixed and the much more polished desktop UX we got out of it;
> # accept that our “sandbox” can be escaped via X11 i.e. revert Bug #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;
> # 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 Feature #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 2017-09-24 08:53:17

> 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 Feature #14713 where I’m going to reply right now.

#18 Updated by anonym 2017-09-28 18:49:06

  • Status changed from Fix committed to Resolved