After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681199 - Keep the caret visible by pushing the view up
Keep the caret visible by pushing the view up
Product: gnome-shell
Classification: Core
Component: keyboard
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
: 707284 791118 (view as bug list)
Depends on:
Reported: 2012-08-04 15:16 UTC by Allan Day
Modified: 2021-07-05 14:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Allan Day 2012-08-04 15:16:36 UTC
Currently, the onscreen keyboard always overlaps the view (windows + background). This means that it can obscure where text is being entered.

The view should be pushed up in circumstances where the caret would otherwise be obscured. The following mockup gives an idea of how this could work:
Comment 1 David King 2014-03-13 14:01:54 UTC
*** Bug 707284 has been marked as a duplicate of this bug. ***
Comment 3 Florian Müllner 2017-01-20 13:46:03 UTC
I'm not sure about this approach. It is certainly easier(*) than the proposed design, but there are a number of drawbacks:

 - resizing windows can trigger relayouts that are moderately
   expensive both in terms of performance and visual noise

 - non-maximized windows that are resized are not restored to
   their user-set size when the OSK pops down

The second issue could be addressed to make sure that windows are vertically maximized while the OSK is open (and unmaximized if necessary when hiding the keyboard). Maybe that would be a good compromise until we (maybe some day) get to implement the original design?

(*) a *lot* easier actually if the shifted windows should still respond to mouse input, as this would require input translation (a first for us on wayland and a no-go on X11)
Comment 4 Jan-Michael Brummer 2017-01-21 16:53:59 UTC
It might be that the behaviour of this extension is not the best (at least android does the same) and the initial design is better. But at least this is a simple and small solution for a generic problem. I'd prefer to help the user of gnome shell with this addition that will work in most of the cases than having no solution at all. Another (and maybe better) solution can be discussed and developed later.
Comment 5 Florian Müllner 2017-01-23 16:06:25 UTC
I'm fine with that as long as you fix the second issue I mentioned in comment #3.
Comment 6 Jan-Michael Brummer 2017-01-23 19:56:59 UTC
I've tried several gnome application which are non-maximized (terminal, contacts, maps, epiphany, ...). All of them gets restored to their previous user defined position/size (tested on wayland). Do you have an example of an application that does not work as expected?
Comment 7 Florian Müllner 2017-01-23 22:55:38 UTC
Are you sure the windows were actually resized rather than just moved? I can reproduce the issue with any apps, including the ones you mention.

For example:

 1. Open nautilus
 2. Move/resize the window to take up most of the screen height
 3. Toggle search button (OSK should pop up)
 4. Toggle search button again (OSD should pop down)

The window keeps the size from step 3 rather than growing back to the size from step 2.
Comment 8 Jan-Michael Brummer 2017-01-24 19:14:00 UTC
Yes, Florian you are right. I've missed this use case... seems to be a bug within shell. I'd suggest adding this extension and opening a new gnome shell bug for this issue.
Comment 9 Florian Müllner 2017-01-26 16:57:07 UTC
Uhm, no. That's simply how mutter's work area code works (and has worked in metacity since about 2001). If that code needs to be updated to deal with frequent and big work area changes, then that needs to happen before merging the patch. "This patch is super simple as long as you ignore the hard part" doesn't fly, sorry.
Comment 10 Jan-Michael Brummer 2017-02-26 21:35:54 UTC
Florian, i did some further testing with this issue and i can only reproduce it on wayland. Using X there is no issue for this use case.

Can you guide me into the difference between X and wayland code within mutter? So the code did change since 2001.
Comment 11 Florian Müllner 2017-12-02 01:48:37 UTC
*** Bug 791118 has been marked as a duplicate of this bug. ***
Comment 12 GNOME Infrastructure Team 2021-07-05 14:15:11 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.