Attached captures before and after writing ⅜

Deleted: Captura de pantalla de 2018-03-22 19-28-48.png 727 bytes

	Captura de pantalla de 2018-03-22 19-28-48.png 727 bytes View Download

Deleted: Captura de pantalla de 2018-03-22 19-28-24.png 1.1 KB

	Captura de pantalla de 2018-03-22 19-28-24.png 1.1 KB View Download

Also happening on ToT.

xdai@ and mukai@, is this still your area?

I don't work on font rending related area any more.

Does mukai@?  Or do you know who does these days?

Surely kinda my area, but I'm not actively working on this either.

By the way, it does not reproduce on my environment -- and I guess it's very likely to be depending on the used font. What font is used here, and also wondering if this is chrome specific -- is this not happening on other applications like gedit?

I could not reproduce it in gedit, but I agree it depends on the font.

The reported test case was using Chromium X11 64 stable on Ubuntu 17.10. But I just tested and it is also happening in 65.

I think the Chromium X11 fonts are controlled in Chromium side?

I tried on gedit and epiphany and could not reproduce the issue. Also, the issue only happens on aura controls in Chromium, but not on web contents. But I don't know the font Chrome is using by default for omnibox (that does not seem to be gnome shell font).

Chromium chooses the font through fontconfig, but the choosing mechanism might be different from standard Gtk3 apps like gedit. It would be helpful if you find out which font is used there -- but I guess your system has tons of pre-installed fonts.

I'm also wondering if this is omnibox only or for whole chrome (i.e. happening within web contents). You could open a tab like data:text/html,<textarea>%C2%B1</textarea><br><textarea>%C2%B1%E2%85%9C</textarea> to check this.

I think +msw should have insights on this area.

It's probably specific to View textfields, which apply fallback fonts by text run, rather than per-character (like Blink).
If the font used for ± doesn't have a glyph for ⅜, then both will be rendered with a fallback font that has glyphs for both.

This is 'by design' of the gfx::RenderText system, though I think we've decided that per-character fallback would be better.
Morphing this bug to loosely track the effort to implement per-character fallback in views::Textfield/gfx::RenderText.
No one is actively working on this area, and a low severity bug like this probably won't be fixed anytime soon.

Maybe we could help implementing this... But at least for considering that, it'd would be good to have some explanation of where this dependency is introduced, and some hints on how to move the implementation to consider glyph fallbacks per char.

ui/gfx/render_text_harfbuzz.cc and apparently ui/gfx/font_fallback.h
It's likely not a simple change. Alexei's had related ideas in the past about fallback and caching.

*** UI Mass Triage ****