Able to reproduce this issue on Ubuntu 14.04 on latest stable 62.0.3202.75 and on latest Dev 64.0.3251.0 with the steps mentioned in the original comment.
Issue is not observed on Windows 7 and Mac OS 10.12.6.

Bisect Information:
=====================
Good build: 62.0.3166.0 (Revision-489161)
Bad Build : 62.0.3167.0 (Revision-489499)

Change Log URL: 
===============
https://chromium.googlesource.com/chromium/src/+log/92b3e938ceb8864b94280ce89272cd90fa746dbb..76f82679ebf31c2144fe1af32b91ec62d22706fe

From the above change log the possible CL suspect is:
Reviewed-on: https://chromium-review.googlesource.com/578232

estade@ Could you please check whether this issue is caused with respect to your change, if not please help us in assigning it to the right owner.

Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove it if this is not the case.

Thanks...!!

tapted@,
Could you please take a look into this as it is marked as stable blocker.
Thanks..!

Why is this a stable blocker? m62 has shipped - we can't block it. Also we don't support users doing --force-device-scale-factor=1.2 -- that's mainly for testing. This seems low priority. estade is back soon.

Scaling fonts and pages for large monitors is supported via chrome://settings -- "Page zoom" and "Customise fonts".

> Scaling fonts and pages for large monitors is supported via chrome://settings -- "Page zoom" and "Customise fonts".

I have my fonts set to size 16 but that:
- does not fix fonts for browser menus
- does not fix the microscopic fonts of extension icons (reported in this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=617362)

Also increasing minimum font size creates additional issues (e.g. misplacement of HTML elements) with some web pages (which are simply made for smaller fonts).

So considering there is no setting to control browser UI elements, users with large and high dpi monitors have no other way to avoid eye strain except using --force-device-scale-factor and that itself creates other issues (like the current one).

One additional issue (expected effect) which --force-device-scale-factor creates is obviously the stretching of images which practically results in lowering actual dpi resolution. So one may have a 100dpi monitor and is forced to use it as lower dpi while browsing because of all this.

I don't know if this should be added into some separate issue but there must be a way to control UI element sizes independently (and without --force-device-scale-factor)

1.2 is a pretty oddball scale factor and I expect there are problems throughout the UI when you use it. I'd expect there to be fewer issues at, e.g., 1.5x. I'm no longer working on fixing fractional scale factor issues because Oshima has a project to fix them comprehensively.

> 1.2 is a pretty oddball scale factor and I expect there are problems throughout the UI when you use it.

I have chosen 1.2 because in earlier versions (5x.*) there was blurring even on the menus with bigger and smaller factors. So visually it looked like least worse so I stayed with it.

> I'd expect there to be fewer issues at, e.g., 1.5x. I'm no longer working on fixing fractional scale factor issues because Oshima has a project to fix them comprehensively.

With 1.5x the issue remains. Tried also 1.25 and 1.3 - still the same.

malaykeshav@, i think this is fixed?

Continuing the discussion on the bug.
So far it seems that the issue happens due to the masking we apply to get the rounded corners in the extension popup.

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/extensions/extension_popup.cc?gsn=ExtensionPopupAura&g=0&l=147

From discussion with @trchen
Adding a mask results in the layer having its own render surface. which means "all layers in the subtree must first draw into that render surface, then that render surface will have mask applied while drawing into its target render surface.
And the fuzziness are from the resampling errors during the draw, which is due to a sampling space mismatch."

@danakj @trchen -
However I don't understand why there is a sampling space mismatch. The render surface with the mask should be of the same size as its parent render surface?

If the bluriness is due to the subpixel position offset not propagating due to the new render surface, is it possible to apply a new subpixe position offset to the ui::Layer that has the mask layer to fix this?
https://cs.chromium.org/chromium/src/ui/compositor/layer.h?dr=CSs&g=0&l=532

+wei for masks, it sounds like this is https://bugs.chromium.org/p/chromium/issues/detail?id=843250