Project

General

Profile

Feature #10263

Bug #10250: Eliminate manual test suite

Test that the on-screen keyboard works and its layout is correctly set

Added by kytv almost 4 years ago. Updated almost 2 years ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
-
Start date:
09/26/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
On-screen keyboard

Description

The screen keyboard must:

  • work in Tor Browser when activated after the browser has started;
  • work in Thunderbird when activated after Thunderbird has started;
  • be auto-configured to use the same keyboard layout as the X session (this does not work yet with GNOME's on-screen keyboard, see #8444 for details).

Related issues

Related to Tails - Feature #8444: Monitor development of screen keyboard in GNOME Confirmed 12/16/2014
Related to Tails - Bug #14675: GNOME on-screen keyboard is broken without the X11 XTEST extensions Resolved 09/16/2017

History

#1 Updated by kytv almost 4 years ago

  • Parent task set to #10250

#2 Updated by intrigeri about 2 years ago

  • Affected tool set to On-screen keyboard

#3 Updated by intrigeri about 2 years ago

  • Subject changed from Test that the virtual keyboard is correctly set to Test that the virtual keyboard layout is correctly set

#4 Updated by intrigeri about 2 years ago

  • Subject changed from Test that the virtual keyboard layout is correctly set to Test that the on-screen keyboard layout is correctly set
  • Description updated (diff)

#5 Updated by intrigeri about 2 years ago

  • Related to Feature #8444: Monitor development of screen keyboard in GNOME added

#6 Updated by intrigeri about 2 years ago

  • Related to Bug #14675: GNOME on-screen keyboard is broken without the X11 XTEST extensions added

#7 Updated by intrigeri about 2 years ago

  • Subject changed from Test that the on-screen keyboard layout is correctly set to Test that the on-screen keyboard works and its layout is correctly set

#8 Updated by anonym almost 2 years ago

When testing Tails 3.2 it was noticed that if GNOME screen keyboard is started after Tor/Unsafe Browser, then clicking text entries inside the browser won't show the screen keyboard. Restarting the browser fixes it. And it's not a problem if the screen keyboard is enabled before starting the browser, so this is IMHO not a big issue.

#9 Updated by intrigeri almost 2 years ago

When testing Tails 3.2 it was noticed that if GNOME screen keyboard is started after Tor/Unsafe Browser, then clicking text entries inside the browser won't show the screen keyboard. Restarting the browser fixes it. And it's not a problem if the screen keyboard is enabled before starting the browser, so this is IMHO not a big issue.

I guess this problem has the same root cause as #9260.

#10 Updated by anonym almost 2 years ago

I believe I recall it mentioned during the testing of this feature, before it was merged, that for some of our supported locales, the on-screen keyboard doesn't represent the locale's keyboard so well. Examples:

  • German is indeed qwertz, but it lacks a buttons for üäö (workaround: long-pressing uao -> menu where the umlaut version can be inserted)
  • Spanish is qwerty but lacks ñ (but long-press on n works)

Apparently the long-pressing on screen keyboard buttons to get more options (e.g. adding ¨`´~ to the character) is common on mobile devices, so I guess most users will figure it out, but I think we should document this for those that won't.

#11 Updated by anonym almost 2 years ago

The delay for long-pressing to open the menu is pretty long, about ~1 second (but on Android it feels like it is perhaps 250ms, which feels a lot better, IMHO). Actually, my firsts attempt (after being suggested this by an Android user :)) failed because I expected a shorter delay. :)

We should ask upstream to consider lowering it, and possibly do so ourselves early if it's configurable.

#12 Updated by intrigeri almost 2 years ago

When testing Tails 3.2 it was noticed that if GNOME screen keyboard is started after Tor/Unsafe Browser, then clicking text entries inside the browser won't show the screen keyboard. Restarting the browser fixes it. And it's not a problem if the screen keyboard is enabled before starting the browser, so this is IMHO not a big issue.

Please report this as a dedicated bug (regression actually). You can assign it to me if you want. I'm not sure about the "not a big issue" thing, I'll need to test how it works for our two main scenarios ("I need an on-screen keyboard all the time" and "I want to use the on-screen keyboard occasionally to type passwords") before I can build an informed opinion about it.

#13 Updated by intrigeri almost 2 years ago

Apparently the long-pressing on screen keyboard buttons to get more options (e.g. adding ¨`´~ to the character) is common on mobile devices, so I guess most users will figure it out, but I think we should document this for those that won't.

Please file a dedicated ticket (assigned to me) about it. I'll check what doc I've written and what's missing.

#14 Updated by intrigeri almost 2 years ago

The delay for long-pressing to open the menu is pretty long, about ~1 second (but on Android it feels like it is perhaps 250ms, which feels a lot better, IMHO). Actually, my firsts attempt (after being suggested this by an Android user :)) failed because I expected a shorter delay. :)

We should ask upstream to consider lowering it, and possibly do so ourselves early if it's configurable.

Same, dedicated ticket please :)

#15 Updated by intrigeri almost 2 years ago

anonym wrote:

Apparently the long-pressing on screen keyboard buttons to get more options (e.g. adding ¨`´~ to the character) is common on mobile devices, so I guess most users will figure it out, but I think we should document this for those that won't.

FTR our doc about the screen keyboard points to the upstream one, that does not document this feature. Wrt. "we should document this", I'll do it if help desk tells us that there are people who did not figure it out and have looked at our doc.

#16 Updated by intrigeri almost 2 years ago

intrigeri wrote:

When testing Tails 3.2 it was noticed that if GNOME screen keyboard is started after Tor/Unsafe Browser, then clicking text entries inside the browser won't show the screen keyboard. Restarting the browser fixes it. And it's not a problem if the screen keyboard is enabled before starting the browser, so this is IMHO not a big issue.

Please report this as a dedicated bug (regression actually).

That's now #14752.

#17 Updated by intrigeri almost 2 years ago

anonym wrote:

The delay for long-pressing to open the menu is pretty long, about ~1 second (but on Android it feels like it is perhaps 250ms, which feels a lot better

That's now #14753.

#18 Updated by intrigeri almost 2 years ago

So I think I've now filed tickets for all reported issues I think we should take care of. Let's now refocus this ticket on what it is about, i.e. automated tests: adding notes that will help implementing this is great (e.g. the long-press hint is useful), but please report issues that may affect human users on dedicated tickets. Thanks!

#19 Updated by intrigeri almost 2 years ago

  • Description updated (diff)

(Clarified what needs to be tested as per 995662290f3de206243a95812b19ef4b984cf776)

Also available in: Atom PDF