Bug 1521077
Summary: | Input of '?', 'ä', 'ö', 'ü', etc with Gnome OSK | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Michael Boisvert <mboisver> | ||||
Component: | mutter | Assignee: | Florian Müllner <fmuellner> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.5 | CC: | alanm, cgarnach, cww, dkochuka, fmuellner, jkoten, juan.martinez, jwright, kasmith, mboisver, mclasen, perry_yuan, petersen, pnemade, psatpute, pvarma, pyuan, salmy, smaitra, sshedmak, tpelka | ||||
Target Milestone: | rc | Keywords: | i18n, Reopened, ZStream | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1625306 1640925 1640926 (view as bug list) | Environment: | |||||
Last Closed: | 2018-10-30 10:20:09 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1507957, 1526257, 1549949, 1567830, 1625306, 1640925, 1640926 | ||||||
Attachments: |
|
Description
Michael Boisvert
2017-12-05 18:43:44 UTC
Are we gonna fix it during 7.5 release please? No we will postpone this to RHEL 7.6 Parag, Jiri, is this really a regression? 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. If this is not a regression I would like to remove the Regression keyword and Blocker flag. Thanks Parag for detail info. May we get devel and release ack please. 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. Can someone test if this worked with 7.4 say? I can reproduce "cannot input ?" on my local 7.5 instance. I am testing in Japanese locale desktop with ibus running. I can't input '"' either. I start Caribou from gnome-control-center -> Accessibility -> Screen Keyboard Let me try with 7.5 once. checking with 7.4 as well. 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. (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. I think Parag also reproduced on RHEL 7.5. The question is was it working on RHEL 7.4 and earlier? I think Satya says it's same on 7.4 Removing the Regression keyword and BLocker flag until we should find it is otherwise. Also note that Caribou will likely be dropped from 7.6 since its functionality is replaced by gnome-shell in GNOME 3.28. 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. *** Bug 1565432 has been marked as a duplicate of this bug. *** Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. For posterity sake, I am still seeing this issue in 7.6 on gnome-shell-3.28.2-1. Hmm yeah I can reproduce this too... (same gnome-shell-3.28.2-1.el7) (I tested with Japanese locale (ja_JP.utf8)) Michael, what locale are you running? (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 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. @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 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. This has been fixed upstream now: https://gitlab.gnome.org/GNOME/mutter/commit/2e0d758811e51dfaa2d634f On a fresh 7.6 installation, I am now seeing the screen keyboard not presenting itself on 90% of text input boxes, including gedit. (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. 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? 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.
(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. Understood. In that case I can verify this bug as being fixed. (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. (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. (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. Hey Florian, any news on the prior? 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 |