Chrome should respect the Windows 10 text scale factor preference |
|||||
Issue descriptionWindows 10 has "Make text bigger" in the Ease of Access center, Chrome should respect that. We have feedback directly from Microsoft that users would like Chrome text to get bigger too. Microsoft's suggestion is that we just change the zoom percentage for the web, i.e. we make everything bigger not just the text. That ensures sites continue to reflow properly. Changing the text size only tends to cause problems beyond a few percent. Here's the property: https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.textscalefactor We can listen to this message to find out when it changes: https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.textscalefactorchanged
,
Jul 26
does that mean the "Font size" setting would be removed?
,
Aug 23
A few notes: - I still do not have access to a development machine which has this setting - The setting appears to be UWP-only I am going to reach out to Microsoft and see if I can get any clarification.
,
Aug 23
,
Aug 23
,
Sep 14
Code being submitted causes Chrome to scale with Text Zoom factor as well as DPI. Chrome will correctly scale itself if text zoom changes while it is running. Scale changes affect both browser and content. Known issue: Tab, menu, and bookmark text may be too large when starting Chrome on a PC with Text Zoom set > 100%.
,
Sep 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e56906982cb88bb6c21e3e97dee90aff59a49785 commit e56906982cb88bb6c21e3e97dee90aff59a49785 Author: Dana Fried <dfried@chromium.org> Date: Fri Sep 14 20:33:24 2018 Respect Windows Text Zoom accessibility feature. This change adds an object which can access the UWP accessibility settings and listen on change events. It is used by the Windows implementation of display::Screen to listen for text zoom changes, which we have made the decision to support by changing our overall scaling by the same percentage (as anything more thorough would be prohibitively expensive in the current architecture). We achieve compliance by multiplying DPI and text zoom scaling together, the approach recommended as a stopgap by both our engineers and those working on a11y at Microsoft. Note that while this affects *most* UI within Chrome, it does not affect *all* UI - some elements (such as resize frame) are drawn by the system and are only scaled by DPI. A side effect is that all zoom factors are rounded to the nearest 25%, so for instance, a net zoom of 190% will be rounded up to 200%. This will prevent DPI * Zoom factors that are not even multiples of 25% from creating blurry or smeared Chrome rendering or similar artifacts, which we have already seen as a result of problems with DPI scaling. Another effect is to decouple physical DPI from screen scaling, which has necessitated some small changes to the Windows Glass frame as well as the handler for the DPI changed Windows event. Without these changes serious visual artifacts and DCHECK failures can occur because systems are reporting/using different measurements for DPI. Changes to the Glass frame were necessary because Windows paints the resize handle around the window and does not use the text scale factor as part of its size calculation. Bug: 866513 Change-Id: Ia99d1f3c1b2aff973d63bd7ff637b01f166cd843 Reviewed-on: https://chromium-review.googlesource.com/1214747 Reviewed-by: Dan Erat <derat@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Reviewed-by: Robert Liao <robliao@chromium.org> Reviewed-by: Trent Apted <tapted@chromium.org> Commit-Queue: Dana Fried <dfried@chromium.org> Cr-Commit-Position: refs/heads/master@{#591459} [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/chrome/browser/ui/views/frame/glass_browser_frame_view.cc [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/BUILD.gn [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/dpi.cc [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/dpi.h [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/screen_win.cc [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/screen_win.h [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/screen_win_unittest.cc [add] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/uwp_text_scale_factor.cc [add] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/display/win/uwp_text_scale_factor.h [modify] https://crrev.com/e56906982cb88bb6c21e3e97dee90aff59a49785/ui/views/win/hwnd_message_handler.cc
,
Sep 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e20be5528c89db23814b51989719a7f8eb78b267 commit e20be5528c89db23814b51989719a7f8eb78b267 Author: Dana Fried <dfried@chromium.org> Date: Fri Sep 14 23:01:21 2018 Small formatting/comment fixes. Bug: 866513 Change-Id: I92abdf6f00cb59ef3c7193a3543a41a2fe4b4b6b Reviewed-on: https://chromium-review.googlesource.com/1227364 Reviewed-by: Robert Liao <robliao@chromium.org> Commit-Queue: Robert Liao <robliao@chromium.org> Cr-Commit-Position: refs/heads/master@{#591512} [modify] https://crrev.com/e20be5528c89db23814b51989719a7f8eb78b267/ui/display/win/screen_win.cc
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e692ee47ec9e6bf4729e24ef6c6cfd16b4ae48f2 commit e692ee47ec9e6bf4729e24ef6c6cfd16b4ae48f2 Author: Dana Fried <dfried@chromium.org> Date: Tue Sep 18 00:40:39 2018 Fix an issue regarding how COM initializes out params. Bug: 866513 Change-Id: Ie4d551d8a2f995dc04793a9a26ef9e970df56918 Reviewed-on: https://chromium-review.googlesource.com/1229298 Reviewed-by: Robert Liao <robliao@chromium.org> Commit-Queue: Dana Fried <dfried@chromium.org> Cr-Commit-Position: refs/heads/master@{#591899} [modify] https://crrev.com/e692ee47ec9e6bf4729e24ef6c6cfd16b4ae48f2/ui/display/win/uwp_text_scale_factor.cc
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eeb7bfd6cccbef9add25fa30f401b68a2efef054 commit eeb7bfd6cccbef9add25fa30f401b68a2efef054 Author: Dana Fried <dfried@chromium.org> Date: Mon Sep 24 22:57:41 2018 Unscale text by Windows Text Scaling factor to avoid double-scaling. Eliminates text rendering artifacts resulting from launching Chrome browser with Windows Text Zoom enabled. ---------- Background ---------- The new Windows Text Zoom accessibility feature scales small text on the screen by an amount in addition to normal DPI scaling. In consultation with MS accessibility engineers, we have decided that rather than doing complex and extensive scaling math in Chrome, we are just going to have the browser scale additionally by that factor. Chrome now scales dynamically with the zoom factor. When we read default system fonts (such as those used by the views::Label class - used by tabs, menu items, bookmarks, etc.), Windows reports the logical size of the font. This does not take DPI into account, but it *does* take the Windows Text Zoom amount into account (for backwards-compatibility with apps that don't read it directly). When the UI renders the text, it scales by the overall browser scale factor (which includes both DPI and Windows Text Zoom). So effectively, if the Text Zoom is set before Chrome starts, all system-default text ends up scaled *twice*. Correct text size (current behavior only if Text Zoom is changed *after* launching Chrome): Text Scale 100% 150% 200% DPI 100% 12 18 24 DPI 150% 18 27 36 DPI 200% 24 36 48 Current text size if Text Zoom is enabled prior to launching Chrome: Text Scale 100% 150% 200% DPI 100% 12 27 48 DPI 150% 18 39 72 DPI 200% 24 54 96 ------------- Patch Details ------------- This change captures the situations in which we ask Windows for a system font (for menus and captions), and removes the additional scaling done by the OS, since we are already taking this into account when rendering text. We already apply scaling for localization in most of these places for similar reasons, so there is a precedent. Chrome still scales appropriately when Text Scale Factor or DPI is set prior to Chrome launch or changed dynamically while Chrome is running. ---------- Follow-Ups ---------- We call GetNonClientMetrics() in a number of plces, and use LOGFONT* structs as well. These are Windows implementation details and should ideally be hidden away from browser code. We should consolidate to a single cache of system fonts, which will internally ensure that the fonts are scaled appropriately (preferably in gfx::PlatformFontWin or similar). Bug: 866513 Change-Id: Ideb248e2f196bb93d46a3f60780c68cf31446097 Reviewed-on: https://chromium-review.googlesource.com/1235313 Commit-Queue: Dana Fried <dfried@chromium.org> Reviewed-by: Robert Liao <robliao@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#593732} [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/chrome/browser/chrome_browser_main_win.cc [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/content/browser/renderer_host/render_view_host_impl.cc [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/ui/display/win/dpi.cc [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/ui/display/win/dpi.h [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/ui/display/win/uwp_text_scale_factor.cc [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/ui/display/win/uwp_text_scale_factor.h [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/ui/views/controls/menu/menu_config_win.cc [modify] https://crrev.com/eeb7bfd6cccbef9add25fa30f401b68a2efef054/ui/views/widget/native_widget_aura.cc
,
Sep 24
,
Sep 24
Code cleanup not critical to this issue can be found at issue 888788 . |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dmazz...@chromium.org
, Jul 25