Issue metadata
Sign in to add a comment
|
Starting with Chrome 59, Chrome ignores DPI settings in X
Reported by
bj.car...@gmail.com,
Jun 12 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Steps to reproduce the problem: 1. On a Linux machine with a HiDPI display and using X 2. Upgrade to Chrome > 59 3. Open Chrome What is the expected behavior? Chrome will open with an appropriately scaled UI bvased on the DPI settings set in xrand What went wrong? Chrome opens with no UI scaling whatsoever and is basically unreadable and unusable on a HiDPI screen. In my case, the screen is a 13" 4K display on a Dell XPS. I can barely read what I am typing on this bug report from the updated browser. Did this work before? Yes 58.0.3029.110-1 Chrome version: 59.0.3071.86 Channel: stable OS Version: Ubuntu 16.04 Flash Version: I reported this issue on the Product Forums while Chrome 59 was still in Beta and was told that I shouldn't worry about it because the Beta build frequently had issues. The date I initially noticed this issue was May 12, 2017 however it likely started happening a couple of days prior to that.
,
Jun 13 2017
,
Jun 14 2017
Is the variable GDK_SCALE set to 2 in your environment?
,
Jun 14 2017
GDK_SCALE is not set. Setting such a value makes no difference.
,
Jun 14 2017
what's the output of gtk-query-settings?
,
Jun 14 2017
Also, do other GTK apps (eg. gtk3-widget-factory) have the same problem?
,
Jun 14 2017
Only chromium is experiencing this issue, which started at chromium 59. gtk3-widget-factory is scaling correctly. Experimentation has shown that it reads Xft.dpi from xrdb. Note that I don't use a desktop environment (e.g. gnome) I use xmonad, launched by startx. See https://github.com/alex-courtis/arch gtk-query-settings, xrdb and xdpyinfo output attached.
,
Jun 16 2017
,
Jun 16 2017
Same as above, this is only happening in Chromium > 58. I am also not using Gnome, I am using KDE. GTK_SCALE is empty. My X start command passes a dpi value which works fine for many apps (including Chromium < 59) but does not work with Chrome > 58.
,
Jun 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b50cab37a165f1f11d9a046d7f3367e4a563a73f commit b50cab37a165f1f11d9a046d7f3367e4a563a73f Author: thomasanderson <thomasanderson@chromium.org> Date: Fri Jun 16 21:08:58 2017 Respect GDK_SCALE and GDK_DPI_SCALE when calculating scale factor This CL is a followup to [1] which used 'gdk-window-scaling-factor' and 'gdk-unscaled-dpi' to calculate the scaling factor. I intentially avoided using the GdkScreen API for this since the required functions were added in version 3.9.10, and opted to get the settings directly. This doesn't work all the time though, because GTK allows overriding these settings with the GDK_SCALE and GDK_DPI_SCALE environment variables (but only when using the X11 backend). This CL makes the change to use those functions, at the cost of bumping the required GTK dep from 3.3.16 to 3.9.10 (the oldest distro we support, Trusty, has 3.10.8). As a bonus, GdkScreen has a separate scale factor per monitor, so we can finally stop using the global scale factor for all monitors. [1] https://codereview.chromium.org/2899943002/ BUG= 730757 , 732440 R=erg@chromium.org,thestig@chromium.org CC=oshima@chromium.org Review-Url: https://codereview.chromium.org/2937623006 Cr-Commit-Position: refs/heads/master@{#480167} [modify] https://crrev.com/b50cab37a165f1f11d9a046d7f3367e4a563a73f/chrome/browser/ui/libgtkui/gtk_ui.cc
,
Jun 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a7494e43f3d82f3e6232d8b7d26aa175f617aead commit a7494e43f3d82f3e6232d8b7d26aa175f617aead Author: thestig <thestig@chromium.org> Date: Fri Jun 16 22:10:25 2017 Fix up Linux packaging deps after r480167. BUG= 730757 , 732440 TBR=thomasanderson@chromium.org NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2944703003 Cr-Commit-Position: refs/heads/master@{#480193} [modify] https://crrev.com/a7494e43f3d82f3e6232d8b7d26aa175f617aead/chrome/installer/linux/debian/expected_deps_x64_jessie
,
Jun 21 2017
The speculative fix has landed and is now in the dev channel. Can anyone still repro this issue with the latest google-chrome-unstable (which is 61.0.3135.4 as of today)?
,
Jun 21 2017
Version 61.0.3137.0 (Developer Build) (64-bit) works on my machine. It's scaling correctly, based on the Xft.dpi setting. Many thanks!
,
Jun 21 2017
Removing Needs-Bisect label as Bugdriod comment has already been landed. If not please add it back. Thanks!!
,
Jun 22 2017
Issue 730757 has been merged into this issue.
,
Jun 22 2017
,
Jun 22 2017
This bug requires manual review: DEPS changes referenced in bugdroid comments. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 23 2017
Approving merge to M60.
,
Jun 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8d1845c2267b05df565fa33e3c5e2b0e242a21cc commit 8d1845c2267b05df565fa33e3c5e2b0e242a21cc Author: thomasanderson <thomasanderson@chromium.org> Date: Fri Jun 23 21:42:57 2017 [Merge to M60] Respect GDK_SCALE and GDK_DPI_SCALE when calculating scale factor > This CL is a followup to [1] which used 'gdk-window-scaling-factor' > and 'gdk-unscaled-dpi' to calculate the scaling factor. I intentially > avoided using the GdkScreen API for this since the required functions > were added in version 3.9.10, and opted to get the settings directly. > This doesn't work all the time though, because GTK allows overriding > these settings with the GDK_SCALE and GDK_DPI_SCALE environment > variables (but only when using the X11 backend). > > This CL makes the change to use those functions, at the cost of > bumping the required GTK dep from 3.3.16 to 3.9.10 (the oldest distro > we support, Trusty, has 3.10.8). > > As a bonus, GdkScreen has a separate scale factor per monitor, so we > can finally stop using the global scale factor for all monitors. > > [1] https://codereview.chromium.org/2899943002/ > > BUG= 730757 , 732440 > R=erg@chromium.org,thestig@chromium.org > CC=oshima@chromium.org > > Review-Url: https://codereview.chromium.org/2937623006 > Cr-Commit-Position: refs/heads/master@{#480167} BUG= 732440 TBR=erg@chromium.org,thestig@chromium.org CC=oshima@chromium.org NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Review-Url: https://codereview.chromium.org/2961473002 Cr-Commit-Position: refs/branch-heads/3112@{#454} Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897} [modify] https://crrev.com/8d1845c2267b05df565fa33e3c5e2b0e242a21cc/chrome/browser/ui/libgtkui/gtk_ui.cc [modify] https://crrev.com/8d1845c2267b05df565fa33e3c5e2b0e242a21cc/chrome/installer/linux/debian/expected_deps_x64_jessie
,
Jun 23 2017
Should be fixed in Chrome version 60. Please open a separate bug if you have further issues.
,
Jun 28 2017
Unable to test the issue due to unavailability of Ubuntu 16.04 with high DPI display. Could anyone from MTV-team please help us in testing the issue. Hence, adding label TE-NeedsTriageFromMTV for further investigation. Thanks...!! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by acour...@atlassian.com
, Jun 13 2017