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 659643 - fix keyboard window-displacement code
fix keyboard window-displacement code
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: keyboard
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-09-20 21:04 UTC by Owen Taylor
Modified: 2012-02-16 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
window: Fix meta_window_move_frame in the context of the new invisible borders (1.32 KB, patch)
2011-09-20 21:52 UTC, Jasper St. Pierre (not reading bugmail) 		none Details | Review
keyboard: don't try to move windows out of the way of the keyboard (1.01 KB, patch)
2011-09-21 16:49 UTC, Dan Winship 		committed Details | Review
window: Fix meta_window_move_frame in the context of the new invisible borders (1.27 KB, patch)
2011-11-19 20:09 UTC, Jasper St. Pierre (not reading bugmail) 		committed Details | Review

Description Owen Taylor 2011-09-20 21:04:56 UTC 
I can't reproduce this, but I had a situation where every time I tabbed to an terminal, it would hop a few pixels to the right.

Attaching and doing gjs_dumpstack() revealed the problem to be:

 keyboard.js:_moveTemporarily

Which does:

 let rect = currentWindow.get_outer_rect()
 ...
 currentWindow.move_frame(true, newX, newY);

But move_frame() I think now expects a position that corresponds to meta_window_get_input_rect() - with invisible borders.

I'm not sure when _moveTemporarily is called - the keyboard wasn't popped up at the time - but code examination would probably reveal that and how to reproduce the problem.
Comment 1 Florian Müllner 2011-09-20 21:22:41 UTC 
I have been able to reproduce with xchat, when the window is partially covered by the osk.
Comment 2 Jasper St. Pierre (not reading bugmail) 2011-09-20 21:52:29 UTC 
Created attachment 197115 [details] [review]
window: Fix meta_window_move_frame in the context of the new invisible borders

(In reply to comment #0)
> But move_frame() I think now expects a position that corresponds to
> meta_window_get_input_rect() - with invisible borders.

It does -- do we want to keep that interpretation or not? It was just a simple oversight when I was implementing the invisible borders.
Comment 3 Dan Winship 2011-09-21 16:49:53 UTC 
Created attachment 197174 [details] [review]
keyboard: don't try to move windows out of the way of the keyboard

This code was never tested very well, and has several problems
currently (windows creeping down and to the right, windows snapping to
a different location after you move them). To be fixed in 3.4.
Comment 4 Florian Müllner 2011-09-21 17:00:02 UTC 
Review of attachment 197174 [details] [review]:

Looks fine.
Comment 5 Dan Winship 2011-09-22 11:55:46 UTC 
oked on release-team

Attachment 197174 [details] pushed as 57b1695 - keyboard: don't try to move windows out of the way of the keyboard
Comment 6 Jasper St. Pierre (not reading bugmail) 2011-11-19 20:09:38 UTC 
Created attachment 201713 [details] [review]
window: Fix meta_window_move_frame in the context of the new invisible borders

Much simpler patch.
Comment 7 Owen Taylor 2012-02-16 15:51:04 UTC 
Review of attachment 201713 [details] [review]:

Patch looks right and does the right thing in testing
Comment 8 Jasper St. Pierre (not reading bugmail) 2012-02-16 21:47:39 UTC 
Attachment 201713 [details] pushed as c47039d - window: Fix meta_window_move_frame in the context of the new invisible borders