Issue metadata
Sign in to add a comment
|
Gtk3 version of chromium will send wrong coordinates to input method
Reported by
wen...@gmail.com,
Oct 16 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Set env var GDK_SCALE=2 GDK_DPI_SCALE=0.5 2. Use input method under linux 3. Type anything that will trigger a input method window What is the expected behavior? The coordinates send to input method is down-scaled based on gtk settings. What went wrong? IMHO this bug is somewhat related to https://bugs.chromium.org/p/chromium/issues/detail?id=475718 Here's my theory. When chrome scale its interface based on Xft.dpi but not GDK_SCALE or some global GTK settings, the coordinates will be right (gdk scale = 1 but chrome also do the scale). When GDK_SCALE is set, chrome will scale too but it also send the same coordinates regardless of the gdk scale. But the problem is when Gtk im module implementation try to send coordinates, it will try to scale it again based on information from gtk. E.g. https://github.com/ibus/ibus/commit/6a3301db85e77e0652f7e00894cce493b6a942f6#diff-864a9b941d52b5d63b6e352614629072 https://github.com/fcitx/fcitx/blob/master/src/frontend/gtk2/fcitximcontext.c#L1041 This causes the "double" scale comparing to the gtk 2 version of chrome. Also please notice, ibus's latest version does not yet include the commit above. Please use ibus's git, or fcitx's stable to test. Did this work before? Yes Last Gtk2 chrome. Chrome version: 61.0.3163.100 Channel: stable OS Version: 4.13 Flash Version:
,
Oct 17 2017
As per C#0, this looks to be specific to GTK3 and used to work with Gtk2, hence assigning to thomasanderson@(worked on Issue 79722 ) for more inputs and further investigation of this.
,
Oct 17 2017
,
Oct 23 2017
shuchen@ can you take a look at this issue?
,
Nov 15 2017
I cannot repro this on ToT.
,
Nov 17 2017
A new report of this issue is at https://bugs.chromium.org/p/chromium/issues/detail?id=786299.
,
Jan 16 2018
+suzhe@ who may help me better understand the linux specific stuff. I don't understand what is "Gtk3 version of chromium". Does it mean Chromium currently compiled with Gtk3 lib? Or Chromium runs under an environment with Gtk3 configured. Does this issue only repro with the new ibus implementation? Or it also repros with other IME framework (e.g. SCIM, Fcitx, etc.)?
,
Jan 16 2018
> Does it mean Chromium currently compiled with Gtk3 lib? Yes, it means that Chromium is compiled with "use_gtk3=true". > Does this issue only repro with the new ibus implementation? Or it also repros with other IME framework (e.g. SCIM, Fcitx, etc.)? I don't have IBus to test but it can be reproduced with FCITX. Screenshot attached. Chromium is 63.0.3239.132 (Developer Build) (64-bit).
,
Jan 16 2018
^ Chromium is started with: $ GDK_SCALE=2 GDK_DPI_SCALE=0.5 chromium --user-data-dir="$(mktemp -d)"
,
Jan 18 2018
Unfortunately, I still cannot repro this issue. $> gn args out/chrome_local <there are 3 flags: is_component_build=false is_debug=false use_gtk3=true> $> ninja -C out/chrome_local -j100 chrome $> GDK_SCALE=2 GDK_DPI_SCALE=0.5 out/chrome_local/chrome --user-data-dir=~/.temp Please see the attached screenshot.
,
Jan 18 2018
Because ibus has its own bug on hidpi. If you try to use same env var on any other regular gtk3 application (e.g. gtk3-demo, gedit), you will notice that ibus shows input window with the wrong position. You'll need up-to-date ibus to have this fix so you'll notice the problem. https://github.com/ibus/ibus/commit/6a3301db85e77e0652f7e00894cce493b6a942f6
,
Jan 18 2018
As you can see the ibus hidpi fix is only included in ibus 1.5.17. Which is the latest version released last year in October. It might not be included in your distro, while I had the similar hidpi code for fcitx already in 2015. Well, regardless of input method framework, at least chrome should behave same as other gtk3 applications on this so input method can write code more easily to handle the hidpi.
,
Feb 22 2018
The root cause of the problem is due to that the doc of |gtk_im_context_set_cursor_location| method isn't clear about whether its parameter |area| is in DIP (Device-independent pixel). I can go for an easy fix to just do the check of GTK_CHECK_VERSION(3, 10, 0), but that will break some users (like myself) with old ibus installed. Any better solution?
,
Feb 22 2018
DIP: Density-Independent Pixel.
,
Apr 27 2018
I confirm this bug and add some info. First you need a HiDPi (4K or others) screen to reproduce this bug, which is confirmed with iBus devs, use a normal screen with GDK params seems unable to reproduce it. Second, using Chromium under KDE/Plasma cannot reproduce this bug, only under GNOME it shows, I see one in here seems using iBus under KDE to reproduce this, but it failed.
,
Apr 27 2018
I'm afraid it's hard to be sane with both versions of IBus, without actively detecting IME program and version, which would look dirty and bloated. But in my point of view, being correct on this issue is more important than maintaining compatibility with broken old software since other IME programs do not have this bug, and people will eventually upgrade their IBus.
,
May 16 2018
Such an issue is reproducible in Version 67.0.3396.48 under Ubuntu 18.04, with Gnome 3.28. Just to add a few details: 1. The input selection works when typing in Chrome's address bar. However, the selection window would be nowhere to be found if the typing was done in window elements of a website. 2. Same issue when typing in Chrome extension such as Google Hangouts.
,
May 17 2018
Issue 821255 has been merged into this issue.
,
Aug 21
Still find this bug with 68.0.3440.106, it annoys everyday, I think there is no need to keep compatibility with buggy old version iBus...
,
Aug 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5a19eb524012d2eb81339eeac2b4e5fe2bf45c2b commit 5a19eb524012d2eb81339eeac2b4e5fe2bf45c2b Author: Shu Chen <shuchen@google.com> Date: Fri Aug 24 05:07:31 2018 Making correct coordinates for the new version of iBus. Turns out the new version of iBus (starting from 1.5.17) will multiply the coordinates with the scale factor specified by GDK_SCALE. Chrome on linux now send the system based coordinates to the system's gtk-base IME, despite the scale factor specified by the app. The correct coordinates should be divided by the GDK_SCALE of the app window. Bug: 774974 Change-Id: I654bacaa1a4eaba13680a33f2516e41b35d31a13 Reviewed-on: https://chromium-review.googlesource.com/1186291 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Shu Chen <shuchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#585683} [modify] https://crrev.com/5a19eb524012d2eb81339eeac2b4e5fe2bf45c2b/chrome/browser/ui/libgtkui/x11_input_method_context_impl_gtk.cc
,
Aug 24
,
Aug 24
This should be fixed in M70.
,
Aug 27
Tried testing the issue on build without fix 64.0.3282.186 using Ubuntu 17.10 with HiDPi by following below steps. Steps: ===== 1.Launch chrome. 2.Enabled ibus by executing command "sudo apt install ibus-m17n" 3.Tried to invoke the chromium build by executing command $ GDK_SCALE=2 GDK_DPI_SCALE=0.5 chromium --user-data-dir="$(mktemp -d)" (As per comment #9) but an error popped up as command not found. Attached screenshot for reference. shuchen@ : Could you please check screenshot and let us know if anything is being missed from our end. Requesting you to help us in verifying the fix on the latest M-70 build. Thanks.!
,
Aug 28
With version 70.0.3534.4, the issue is resolved for me on Ubuntu 18.04. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Oct 16 2017