How do you know that's "stretched" and not just a different font size/face?  This doesn't look like a bug to me.

Both are the same Ubuntu Regular font. You can tell by the shape of the G.

http://font.ubuntu.com/

A clear regression IMO, particularly in tabs, which have less text
displayed now. (I should've used a tab with more text, but already had
the image from M51, and didn't want to download it again.)

I forgot to mention that the address bar is not affected by this, and still renders as before.

Deleted: 1.png 3.2 KB

	1.png 3.2 KB View Download

looks like the size changed slightly. Doesn't seem like an issue to me.

I found the culprit.

https://chromium.googlesource.com/chromium/src/+/52c96f45954fb726585acd0bac295d801728b22e%5E%21/

(It's between 397169 and 397176 and only this commit is related.)

I have DPI set lower than 96, which is ignored now. I'm not sure what prompted this change.

Assigning to oshima@ to triage, fix, or close as appropriate.

How are you setting the dpi on X?

Through text-scale-factor on Ubuntu, which does all the rest automatically.

$ dconf read /com/canonical/unity/interface/text-scale-factor

I checked and gtk-xft-dpi is set accordingly.

Linux chrome does not support dynamic scale change. The behavior is undefined after the scale is changed until chrome is restarted, because there are other parts that depends on gtk in chrome. (font etc)

The CL in #8 is to avoid more problematic behavior (see  crbug.com/615353 ).

If you have this even after restarted, my CL is less likely to be a culprit, but I can confirm/test it. Please let me know the value you're using.

The problem is this line, which discards DPI < 96.

dpi = std::max(kDefaultDPI, dpi);

(I don't care about dynamic change.)

I typically run my desktop environment with text/menu/title scaling set to about .85. I feel I get more screen real estate that way. Ever since I updated my Chrome installation yesterday all the Chrome UI elements don't appear to be obeying my scaling setting.

The tab fonts are much larger and I see less information per-tab title. Password prompt popups use a much larger font than any other UI component and finally the bookmarks tab font has increased as well, I see less bookmark folders than I used to.

I don't like it this way. Chrome should obey my GTK UI scaling settings.

As this is a simple fix, may I request it to be merged afterwards. Thanks.

I can confirm text sizing on webpages that do not set font-size is increased in Chrome 52.0.2743.82 (64-bit) on Ubuntu 16.04.

$ xdpyinfo | grep dots
  resolution:    96x96 dots per inch

That value is most likely incorrect. (It's always 96 DPI in Ubuntu.)

You should try https://github.com/derat/font-config-info and report gtk-xft-dpi.

gtk-xft-dpi          98304 (96,00 DPI)

I think you might have a different bug then.

Any update? The limitation to >= 96 DPI is unrelated to the problem fixed in the mentioned CL and arbitrary.

I don't think we plan to support <1x dsf, if that's what you're asking.

Why? Odd decision IMO.

Supporting it doesn't mean just removing the line that disallows it. Supporting it means fixing bugs that crop up throughout Chrome when the scale factor is less than 1, figuring out a way to make our smaller icons look good at <1x scale, etc. The engineering cost is not worth the benefit because very few users have <1x scale.

I think there is a bit of a misunderstanding here. The reason for
users setting DPI < 96 is because quite a few screens have physical
DPI < 96. Matching it improves text display. I don't understand how
this is related to DSF.

And as you mention, there is no "support" anyway. It just works.

https://codereview.chromium.org/2441043002/

For some reason it took another bug report to get this fixed.

https://bugs.chromium.org/p/chromium/issues/detail?id=646254

psknsk: Thanks for the CR link, copied to the bug I reported.

@everyone: working interim fix/hack:

  $ cat ~/.gtkrc-2.0
  gtk-font-name = "Sans 8"

Do something like `GTK2_RC_FILES=path/to/custom/gtkrc chromium` to isolate the font size change to Chrome if you want/need to. More discussion in the bug linked in #27.

I recommend continuing to track this issue (track both bugs, I say) to find out what Chrome's official fix is.

I can confirm that the issue is fixed.

https://chromium.googlesource.com/chromium/src/+/a98afff3156eb88b39f82cfae23d99bed436bb3c

Thanks for filing a duplicate bug report, which for some reason made Google fix this.