Hey Scott, the changes in https://chromium-review.googlesource.com/c/chromium/src/+/1220373 somehow affect the font in other cr-inputs. And it is even more strange that the affected font doesn't become the one we specify in the mixin. Do you have any ideas why this happens?

Added screenshots.

Deleted: Before_Changes.png 16.6 KB

	Before_Changes.png 16.6 KB View Download

Deleted: After_Changes.png 15.5 KB

	After_Changes.png 15.5 KB View Download

Can you post a screenshot of the devtools CSS inspector for the input that should not be affected? What is the font-family? 

Did more debugging on this one, the affected font in other cr-inputs ends up with a generated property as follows:

font-family: var(--cr-input-input_-_font-family,apply-shim-inherit);

It looks like "apply-shim-inherit" will use the browser default font.

Interesting. So firstly that means that the problem only happens with optimize_webui=true (which is the default value).

Secondly, this might be an issue with the polymer-css-build tool invoked in optimized pages. You can see the actual final code under

out/<out_folder>/gen/chrome/browser/resources/settings/vulcanized.html

Renaming the bug as well, since this affects all inputs, and the problem is not the overlapping 'f', but the incorrect font.

Did some more testing:

If we remove "font-family: inherit;" inside #input, "apply-shim-inherit" won't be added into the final code (vulcanized.html).

Who do you think it's the best person to look into this issue? In the meantime, should we revert the change that uses the mixin so that at least not all the cr-inputs will be affected.

Briefly chatted with dfreedm@ from the polymer team. 'apply-shim-inherit' is not the appropriate fallback value for font-family. So this is something that could be fixed in polymer-css-bulid itself.

We can either wait for the fix, or a workaround is the following:

1) Don't use --cr-input-input mixin for setting the font-family.
2) In cr-input expose a dedicated CSS variable just for font-family, for example --cr-input-input-font-family
3) Use that CSS var from password_edit_dialog.html

This looks like a bug where the @apply library tries to handle mixins of the form `--foo: { color: inherit; };`. This mixin should generate `--foo_-_color: apply-shim-inherit`, which is an invalid value to force the `@apply --foo` to invalidate the property and naturally inherit the color value;

The replacement is done as a regexp over the whole string, but it is accidentally targeting fallback values for variables.

I'll have a fix out as soon as possible.

Thanks Daniel. I'll reassign this to you then.

 Issue 890105  has been merged into this issue.

Expecting an updated polymer-css-build version sometime tomorrow, which should address the issue. If that's the case, I don't think we need to land a workaround.

Thanks for the update.

Latest version of polymer-css-build has just been pushed to https://github.com/Polymer/polymer-css-build/commit/c32c64eff2cfb11790bc9a334541f501e4ef1c86. Will try it shortly and verify whether it fixes the issue.

CL candidate at https://chromium-review.googlesource.com/c/chromium/src/+/1252379.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f41e3e132eb8acf717d598db08858ca47312b1ca

commit f41e3e132eb8acf717d598db08858ca47312b1ca
Author: dpapad <dpapad@chromium.org>
Date: Sat Sep 29 00:59:53 2018

WebUI: Update polymer-css-build to version 0.3.3.

The previous version suffered from a bug that caused some properties defined in
CSS mixins to have improper fallback values.

Bug:  888965 
Change-Id: I56c39162bdd2d99ac9a3c370c0fbf22ad359c0b1
Reviewed-on: https://chromium-review.googlesource.com/1252379
Reviewed-by: Scott Chen <scottchen@chromium.org>
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595276}
[modify] https://crrev.com/f41e3e132eb8acf717d598db08858ca47312b1ca/third_party/node/node_modules.tar.gz.sha1
[modify] https://crrev.com/f41e3e132eb8acf717d598db08858ca47312b1ca/third_party/node/package.json

Update:

Rechecked the above issue using latest canary build #71.0.3567.0 on Windows (7, 8, 8.1 ,10) and issue is fixed.
Now,Cursor is seen at proper place with respect to 'f' in Name field of Address section.

Please find below attached screen cast

Thank You...

Deleted: Canary_Behaviour#71.0.3567.0.mp4 571 KB

	Canary_Behaviour#71.0.3567.0.mp4 571 KB View Download

 Issue 889727  has been merged into this issue.