GNOME Bugzilla – Bug 786886
With multiple displays, the candidate window span across the program window to another display
Last modified: 2017-09-04 08:29:49 UTC
Created attachment 358568 [details] Multiple display arrangement Overview: With 2 displays which one above as the primary display and the other in the bottom as the secondary display in arrangement, the candidate window of input methods such as ibus-libzhuyin will span across the program window where the input focus is to the other display when the cursor is at the button of the main window. Steps to Reproduce: 1) Configure at least 2 displays as joint displays. One primary display in the top, and the other secondary display in the bottom. See the attachment for reference. 2) Open gedit or LibreOffice to keep typing anything until the cursor is at the bottom of the program window. 3) activate a input method which will pop up a candidate window before commit the characters to the program, such as ibus-libzhuyin, ibus-libpinyin, ibus-kkc, etc. 4) type any character, and try to change the candidate character in the candidate window. Actual Results: The candidate windows will list the candidates in row which cross the bottom of the program window to the next display. Expected Results: The candidate window of the input method should still be in the same program window as it should be. I recorded a 13 seconds video to demo the issue, please see the attachment.
Created attachment 358569 [details] Candidate window will corss the bottom of the program window to the next display
Created attachment 358570 [details] This is the photo in real world telling why this causes problem
Created attachment 359054 [details] [review] boxpointer: If available, use source actor for constraining If a source actor is set, use that for determining the arrow side (i.e. whether the BoxPointer widget should expand in a certain direction). This is better because it ensures that the popup is displayed on the same monitor as the widget it originates from. Without this, entering text with a vertically aligned input method close to the bottom of a monitor would expand the BoxPointer downwards on the monitor beneath it, instead of upwards, which is what one would expect.
Review of attachment 359054 [details] [review]: Makes sense
Attachment 359054 [details] pushed as 96e14dc - boxpointer: If available, use source actor for constraining