Bug 1732323 - When OSK slide up applications input events delivered into applications as if it window in original position
Summary: When OSK slide up applications input events delivered into applications as if...
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Carlos Garnacho
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-23 07:30 UTC by Deepu K S
Modified: 2019-08-09 17:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)
The attached image shows the window shift, and the area where click is active (76.66 KB, image/png)
2019-07-23 07:30 UTC, Deepu K S
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Gitlab GNOME/gnome-shell/issues/679 None None None 2019-07-23 07:30:32 UTC

Description Deepu K S 2019-07-23 07:30:33 UTC
Created attachment 1592774 [details]
The attached image shows the window shift, and the area where click is active

Description of problem:
When Gnome On Screen Keyboard (OSK) slide up applications input events delivered into applications as if it window in original position.

With current behaviour of OSK, it would push the window to the top if there are any Text Boxes (LineEdits) which is at bottom of page.

Due to this the buttons and Line edit boxes gets moved upwards, but the click/input area still remains at its original position.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 7.6
gnome-shell-3.28.3-6.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Try with any application which has input fields at the bottom of page.
2. 
3.

Actual results:
Gnome On Screen Keyboard (OSK) would overlap on the Line Edits area if there's any at the bottom of window. Hence when the user have to enter text, the window gets shifted such that the Line Edit become fully focused and ready for text input.
However with this shift, the click/input events aren't getting shifted. It behaves as if the window is in its original position.

Expected results:
With window shift the click/input events should also be moved alongwith. The Window Manager ans OSK should handle such scenarios.

Additional info:


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