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 786886 - With multiple displays, the candidate window span across the program window to another display
With multiple displays, the candidate window span across the program window t...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-08-28 08:25 UTC by pswo10680
Modified: 2017-09-04 08:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Multiple display arrangement (73.21 KB, image/png)
2017-08-28 08:25 UTC, pswo10680
  Details
Candidate window will corss the bottom of the program window to the next display (592.58 KB, video/webm)
2017-08-28 08:26 UTC, pswo10680
  Details
This is the photo in real world telling why this causes problem (734.02 KB, image/jpeg)
2017-08-28 08:32 UTC, pswo10680
  Details
boxpointer: If available, use source actor for constraining (1.58 KB, patch)
2017-09-04 06:44 UTC, Jonas Ådahl
committed Details | Review

Description pswo10680 2017-08-28 08:25:17 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.
Comment 1 pswo10680 2017-08-28 08:26:15 UTC
Created attachment 358569 [details]
Candidate window will corss the bottom of the program window to the next display
Comment 2 pswo10680 2017-08-28 08:32:31 UTC
Created attachment 358570 [details]
This is the photo in real world telling why this causes problem
Comment 3 Jonas Ådahl 2017-09-04 06:44:41 UTC
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.
Comment 4 Florian Müllner 2017-09-04 08:21:56 UTC
Review of attachment 359054 [details] [review]:

Makes sense
Comment 5 Jonas Ådahl 2017-09-04 08:29:45 UTC
Attachment 359054 [details] pushed as 96e14dc - boxpointer: If available, use source actor for constraining