Bug 1521077 - Input of '?', 'ä', 'ö', 'ü', etc with Gnome OSK
Summary: Input of '?', 'ä', 'ö', 'ü', etc with Gnome OSK
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mutter
Version: 7.5
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
: 1565432 (view as bug list)
Depends On:
Blocks: 1507957 1567830 1526257 1549949 1625306 1640925 1640926
TreeView+ depends on / blocked
 
Reported: 2017-12-05 18:43 UTC by Michael Boisvert
Modified: 2020-09-29 08:23 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1625306 1640925 1640926 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:20:09 UTC
Target Upstream Version:


Attachments (Terms of Use)
click+drag vs. two clicks (166.73 KB, application/octet-stream)
2018-09-06 16:28 UTC, Michael Boisvert
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1625700 0 high CLOSED On screen keyboard not visible to access with gtk apps 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2018:3140 0 None None None 2018-10-30 10:21:35 UTC

Internal Links: 1625700

Description Michael Boisvert 2017-12-05 18:43:44 UTC
Description of problem: 

The onscreen keyboard returns a "/" when clicking "?" on both the alphabetic and numerical keyboard, so there is no way to create a question mark. The other issue is that none of the special characters, like an e with an umlaut, are able to be produced. Clicking and holding onto the e key opens the pop up but selecting the character results in nothing. 

How reproducible: Always, see description.

Steps to Reproduce:
1. Enable onscreen keyboard through the Accessibility settings. 
2. Open a text editor like gedit.
3. Try to create a question mark, ä, ö, ü, etc. 

Actual results: Cannot create special characters or a question mark. 

Expected results: All selectable characters produce what they are labeled as.

Comment 3 Satyabrata Maitra 2018-01-31 11:43:08 UTC
Are we gonna fix it during 7.5 release please?

Comment 4 Parag Nemade 2018-02-08 05:04:04 UTC
No we will postpone this to RHEL 7.6

Comment 5 Jens Petersen 2018-04-19 04:45:02 UTC
Parag, Jiri, is this really a regression?

Comment 6 Parag Nemade 2018-04-19 07:30:48 UTC
This issue no longer exists with gnome-shell-3.28.1-1.fc28 package. Once Gnome packages are rebased in RHEL-7.6 then this bug will get fixed automatically.

Also, on English locale desktop, I can type '/' -> '/' and '?' -> '?' without issue using caribou on rhel-7.5 but yes accented characters are unable to input.

Comment 7 Jens Petersen 2018-05-02 12:42:41 UTC
If this is not a regression I would like to remove the Regression keyword and Blocker flag.

Comment 8 Satyabrata Maitra 2018-05-04 12:05:15 UTC
Thanks Parag for detail info.
May we get devel and release ack please.

Comment 9 Jens Petersen 2018-05-11 02:44:51 UTC
No, because I don't know if this is a regression - no reason was even given for setting the Regression keyword. In addition as far as we know Caribou no longer works under gnome-3.28.

Comment 10 Jens Petersen 2018-05-11 07:56:05 UTC
Can someone test if this worked with 7.4 say?

I can reproduce "cannot input ?" on my local 7.5 instance.

Comment 11 Jens Petersen 2018-05-11 09:16:20 UTC
I am testing in Japanese locale desktop with ibus running.
I can't input '"' either.

Comment 12 Jens Petersen 2018-05-11 09:25:55 UTC
I start Caribou from gnome-control-center -> Accessibility -> Screen Keyboard

Comment 13 Satyabrata Maitra 2018-05-11 09:58:40 UTC
Let me try with 7.5 once.

Comment 14 Satyabrata Maitra 2018-05-11 10:07:02 UTC
checking with 7.4 as well.

Comment 15 Parag Nemade 2018-05-12 12:47:58 UTC
I am still interested in getting input from the bug reporter.

Michael, Can you tell me when you experienced this bug what locale was you using? what input method keymaps was added in your gnome-session? We need more input to understand the bug reproducing steps.

Comment 16 Michael Boisvert 2018-05-14 02:18:43 UTC
(In reply to Parag Nemade from comment #15)
> I am still interested in getting input from the bug reporter.
> 
> Michael, Can you tell me when you experienced this bug what locale was you
> using? what input method keymaps was added in your gnome-session? We need
> more input to understand the bug reproducing steps.

Totally default installation of 7.5 with USA English selected.

Comment 17 Jens Petersen 2018-05-21 08:11:04 UTC
I think Parag also reproduced on RHEL 7.5.

The question is was it working on RHEL 7.4 and earlier?

Comment 18 Jens Petersen 2018-05-21 08:14:00 UTC
I think Satya says it's same on 7.4

Removing the Regression keyword and BLocker flag
until we should find it is otherwise.

Comment 19 Jens Petersen 2018-05-21 08:15:50 UTC
Also note that Caribou will likely be dropped from 7.6 since
its functionality is replaced  by gnome-shell in GNOME 3.28.

Comment 20 Satyabrata Maitra 2018-05-21 11:08:11 UTC
As we discussed earlier, it is reproducing in 7.4 as well with default en_US installation. So, it doesn't look like a regression. Sandeep and myself is having the same opinion on this.

Comment 21 Karl Hastings 2018-05-22 04:00:05 UTC
*** Bug 1565432 has been marked as a duplicate of this bug. ***

Comment 23 Red Hat Bugzilla Rules Engine 2018-06-28 11:48:08 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 27 Michael Boisvert 2018-07-10 12:46:59 UTC
For posterity sake, I am still seeing this issue in 7.6 on gnome-shell-3.28.2-1.

Comment 28 Jens Petersen 2018-07-31 07:10:29 UTC
Hmm yeah I can reproduce this too... (same gnome-shell-3.28.2-1.el7)

Comment 29 Jens Petersen 2018-07-31 07:33:48 UTC
(I tested with Japanese locale (ja_JP.utf8))

Michael, what locale are you running?

Comment 30 Michael Boisvert 2018-07-31 12:47:02 UTC
(In reply to Jens Petersen from comment #29)
> (I tested with Japanese locale (ja_JP.utf8))
> 
> Michael, what locale are you running?

en_US.UTF-8

Comment 32 Pravin Satpute 2018-08-01 05:17:51 UTC
Thanks Deepu for provide customer portal id.

G11N QE is working test automation for Gnome onscreen keyboard and will cover this test case in future.

Comment 39 Praveen Varma 2018-08-03 01:05:08 UTC
@Jens - My name is Praveen and I am a Escalation Manager looking into the associated case and the situation in hand for Bharath Electronics Ltd. Just a heads up that Sales and SA are pushing a lot of products for BEL and there is a lot at stake for them atm as there are few issues that they are dealing with including this one. Is there a way you can check and let us know as soon as possible on whether we can have a fix on caribou/gnome-shell for 7.5 or if there is a work around?

Thanks a ton in advance !!

Regards,
Praveen

Comment 40 Jens Petersen 2018-08-07 11:02:47 UTC
I think we need to use the Caribou bug(s) for 7.5.
But I think it will be hard to fix 7.5 before 7.6 and Fedora.

Comment 45 Florian Müllner 2018-09-04 14:51:55 UTC
This has been fixed upstream now:
https://gitlab.gnome.org/GNOME/mutter/commit/2e0d758811e51dfaa2d634f

Comment 50 Michael Boisvert 2018-09-05 18:22:55 UTC
On a fresh 7.6 installation, I am now seeing the screen keyboard not presenting itself on 90% of text input boxes, including gedit.

Comment 51 Florian Müllner 2018-09-05 21:15:30 UTC
(In reply to Michael Boisvert from comment #50)
> On a fresh 7.6 installation, I am now seeing the screen keyboard not
> presenting itself on 90% of text input boxes, including gedit.

That clearly sounds like a bug, but unrelated - the patch that landed changes how input from the on-screen keyboard is processed, so that's only invoked once the keyboard has been brought up.

Comment 52 Michael Boisvert 2018-09-06 16:24:04 UTC
The special characters work now, but I cannot select them with a single long click / drag. You need to click and hold the desired character until the special character selection pops up, release the mouse, click once more on the desired special character. Is this expected behavior or should you be able to select the special characters with one longer click?

Comment 53 Michael Boisvert 2018-09-06 16:28:58 UTC
Created attachment 1481359 [details]
click+drag vs. two clicks

Here is a video showing what I mean. First two attempts are a click and drag, second two attempts use two separate clicks.

Comment 54 Florian Müllner 2018-09-06 18:47:41 UTC
(In reply to Michael Boisvert from comment #52)
> Is this expected behavior or should you be able to select the 
> special characters with one longer click?

It's expected behavior. It's probably a good idea to allow both ways of entering extended keys, but it's not what the current code does.

Comment 55 Michael Boisvert 2018-09-06 18:52:14 UTC
Understood. In that case I can verify this bug as being fixed.

Comment 56 Satyabrata Maitra 2018-09-07 04:47:32 UTC
(In reply to Florian Müllner from comment #54)
> (In reply to Michael Boisvert from comment #52)
> > Is this expected behavior or should you be able to select the 
> > special characters with one longer click?
> 
> It's expected behavior. It's probably a good idea to allow both ways of
> entering extended keys, but it's not what the current code does.

From user experience and QE perspective, my opinion is "Release the mouse" action is not that user-friendly and common trend is to click & hold(for a second) to let the special char/list of those pops up, and release mouse on your desired special character to input.

And this is what probably most of us were trying and there was no input, because we were not releasing the mouse in between.

Comment 57 Michael Boisvert 2018-09-07 14:04:18 UTC
(In reply to Satyabrata Maitra from comment #56)
> (In reply to Florian Müllner from comment #54)
> > (In reply to Michael Boisvert from comment #52)
> > > Is this expected behavior or should you be able to select the 
> > > special characters with one longer click?
> > 
> > It's expected behavior. It's probably a good idea to allow both ways of
> > entering extended keys, but it's not what the current code does.
> 
> From user experience and QE perspective, my opinion is "Release the mouse"
> action is not that user-friendly and common trend is to click & hold(for a
> second) to let the special char/list of those pops up, and release mouse on
> your desired special character to input.
> 
> And this is what probably most of us were trying and there was no input,
> because we were not releasing the mouse in between.

Especially because when performing the click+hold onto a special character, the special character pop-up disappears like the selection was made properly.

Comment 58 Deepu K S 2018-09-18 10:08:47 UTC
(In reply to Michael Boisvert from comment #55)
> Understood. In that case I can verify this bug as being fixed.

Do we have a test build available?
Will this be added to our Beta channels?
https://access.redhat.com/downloads/content/rhel---7/x86_64/2484/mutter/3.28.3-1.el7/x86_64/fd431d51/package

Thanks.

Comment 59 Joe Wright 2018-10-18 13:38:05 UTC
Hey Florian, any news on the prior?

Comment 65 errata-xmlrpc 2018-10-30 10:20:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3140


Note You need to log in before you can comment on or make changes to this bug.