1392147 - Map sans-serif to Roboto on Android

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Theme and Visual Design, enhancement, P2)

Description

[Karl Dubost💡 :karlcow]

I'm opening this issue to track the number of Web compat issue we get because of the differences in between the default font on Firefox Android. 

Two cases are happening:
1. The designer didn't specify any default font and it fall backs to the generic font, for example font-family: sans-serif
2. The designer specified a font which is either not installed on the system, or call the font by "Roboto-Regular" instead of "roboto" for example.

The Clear Sans and Roboto have different features which will make them break when centering, adjusting with vertical-align:middle or playing with line-height.



https://webcompat.com/issues/9052
Example on m.zalando.de

```css
html {
	font-family: sans-serif;
	-webkit-text-size-adjust: 100%;
}

.z-navicat-header_userAccNaviItemCounter {
	position: absolute;
	top: -1px;
	left: 60%;
	border-radius: 1em;
	font-size: 10px;
	color: #fff;
	background-color: #666;
	box-shadow: 0 0 0 2px #fff;
	min-width: 1.8em;
	padding: 3px 6px 1px;
	opacity: 1;
	text-shadow: 1px 1px 1px #000;
	transition: opacity .1s ease-in-out;
}
```

The site is probably tested

Comment 1

[Karl Dubost💡 :karlcow]

And just for the sake of avoiding this round of arguments, we all know that 

1. sites should not rely on pixel perfect rendering
2. designers should test their design on multiple devices/browsers

The reality is that there's still breakage. And I'm interested on how we could minimize its effects. And if there are steps we could take to make it "less broken" visually-speaking.

Comment 2

[Karl Dubost💡 :karlcow]

Where setting a letter-spacing: -0.05em will fix the issue for Firefox, but might create an issue for Roboto.

Comment 3

[Nevin Chen(Not active on Bugzilla)]

I'll change the component but feel free to change back

Comment 4

[Jan Henning [:JanH]]

The Product description says "A place to file bugs as they relate to software that deals with web compatibility (more info). Note: site and outreach bugs should be filed in Tech Evangelism." (i.e. things like the addon that powers the "Report site issue" button), which this bug isn't. If we don't want to change our default font (and I'm not arguing we should), then we should just WONTFIX this instead of attempting to get rid of this bug by moving it elsewhere.

Comment 5

[Karl Dubost💡 :karlcow]

Yes agreed with Jan Henning. It has nothing to do with Web Compatibility Tools but the default font on Firefox Android. 
I'm not reporting all issues from webcompat about this issue but maybe I should.

The scenario is a variation on this type of CSS:

body {
    font-family: Helvetica, Arial, sans-serif;
}

On Chrome Android, if Helvetica, Arial are not on the device, it will fallback on Roboto.
On Firefox Android, it will fallback on Open Sans
And it breaks designs on sites because Roboto and Open Sans are really different.


The Firefox Android market shares are low. 
People will not test on Firefox Android (unfortunately business reality).

We can try to contact sites, but the volume of breakage is too important to make it reasonable economically  speaking (another business reality).

I will move it again to Firefox Android, General. You may close it as wontfix. At least I can keep adding the webcompat issue in SeeAlso.

Thanks. :)

Comment 6

[Jonathan Kew [:jfkthame]]

Karl, I don't think the change in the description here (from Clear Sans to Open Sans) was correct. The font family we ship with FF/Android, and configure as the default sans-serif, is Clear Sans (which is a different font from Open Sans, which is widely found on Linux). See bug 877203.

As for whether to switch away from Clear Sans as the default, which I believe was chosen for design/aesthetic reasons, and fall back to Roboto for better compatibility with fragile website layouts (and less differentiation from other browsers), I think that's a call the Firefox/Android product team needs to make.

Comment 7

[Karl Dubost💡 :karlcow]

Ah yes. I had initially created with Clear Sans, I don't remember what got me confused. Anyway agreed with what you said it's why I said.
> You may close it as wontfix.

I will try to write an article comparing Roboto / Clear Sans if I manage to install and discover the font features.

Comment 8

[Karl Dubost💡 :karlcow]

in https://webcompat.com/issues/8068
vertical-align: text-bottom doesn't result in the same alignment for Roboto and Clear Sans.

Comment 9

[Karl Dubost💡 :karlcow]

It's happening too often that I decided to write this.
http://www.otsukare.info/2018/02/09/android-font-css

Comment 10

[Mike Taylor [:miketaylr]]

Hey Andreas, assuming we thought it was a good idea to replace Open Sans with Roboto for Fennec, where would that conversation start?

Comment 11

[Mike Taylor [:miketaylr]]

Snorp, any ideas about the question in Comment #10?

Comment 12

[James Willcox (:snorp) ([e-mail]) (he/him)]

I think we should maybe get a UX person involved? Anthony, do you know who would be interested?

Comment 13

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I'm going to NI Tif and Amin here. They're going to be picking up most of this work from me and we're currently ramping up staffing so it'd be helpful to know specifics around deadlines and what not (if you have them) :)

Comment 14

[Andreas Bovens [:abovens]]

Sorry for the delayed reply.

I might have missed something here, but I don't think this is a UI/UX question. It's about the way the engine handles fonts and fallbacks. Switching to Roboto and aligning with other browsers absolutely makes sense, I think.

So, as for replacing Open Sans with Roboto on the engine side, I guess Snorp should should be able to comment on the complexity involved here.

Comment 15

[Karl Dubost💡 :karlcow]

According to https://bugs.chromium.org/p/chromium/issues/detail?id=641861#c26
and https://stackoverflow.com/questions/19691530/valid-values-for-androidfontfamily-and-what-they-map-to
There are additional subtleties.


Also according to https://github.com/webcompat/web-bugs/issues/8753#issuecomment-375085895

> the only reason we get Roboto on [Chrome] Android is because it [Roboto] is the sans-serif font and aliased from Arial.

Comment 16

[Amin Al Hazwani [:amin] (Firefox UX)]

(In reply to Andreas Bovens [:abovens] from comment #14)
> I might have missed something here, but I don't think this is a UI/UX
> question. It's about the way the engine handles fonts and fallbacks.
> Switching to Roboto and aligning with other browsers absolutely makes sense,
> I think.

I second Andreas here. It makes sense to fallback to Roboto, the platform typeface.

Comment 17

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment #6 indicates that it was in fact a UX/aesthetics decision, but I think we probably care more about the web compat story now, as comment #5 suggests.

I've changed the summary to reflect what I understand as the core issue here. Jonathan, can you make the required change?

Comment 18

[Jonathan Kew [:jfkthame]]

So the proposal here is to switch our default sans-serif font from Clear Sans to Roboto. (This isn't about "fallback", as we usually use the term, it's about the mapping of the CSS generic 'sans-serif' keyword to a specific font family.)

FWIW, if we do this, we may as well drop the Clear Sans fonts entirely from the Android package, saving some APK size in the process. No point in bundling it if we're not going to be using it as our default.

Can we assume Roboto is present (and the appropriate choice for sans-serif) on all devices? (Once upon a time, it would have been Droid Sans, IIRC.) If there are any manufacturers who customize their Android build to have an entirely different set of fonts, and drop Roboto from their build, that could complicate things.

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew (:jfkthame) from comment #18)
> FWIW, if we do this, we may as well drop the Clear Sans fonts entirely from
> the Android package, saving some APK size in the process. No point in
> bundling it if we're not going to be using it as our default.

Actually, now that I think about it, we don't include it in the APK any more, do we? IIRC we now download the fonts on first run, so there won't be any APK size impact here.

Comment 20

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #18)
> So the proposal here is to switch our default sans-serif font from Clear
> Sans to Roboto. (This isn't about "fallback", as we usually use the term,
> it's about the mapping of the CSS generic 'sans-serif' keyword to a specific
> font family.)
> 
> FWIW, if we do this, we may as well drop the Clear Sans fonts entirely from
> the Android package, saving some APK size in the process. No point in
> bundling it if we're not going to be using it as our default.
> 
> Can we assume Roboto is present (and the appropriate choice for sans-serif)
> on all devices? (Once upon a time, it would have been Droid Sans, IIRC.) If
> there are any manufacturers who customize their Android build to have an
> entirely different set of fonts, and drop Roboto from their build, that
> could complicate things.

I think Roboto has been present since 4.0 (API 14), but there were a bunch of enhancements to improve the font in 4.1 (API 16, Fennec's minimum version). So we should be ok, unless as you said some OEM drops it, which seems unlikely...

https://developer.android.com/about/versions/android-4.1.html

Comment 21

[Karl Dubost💡 :karlcow]

This is an interesting question.

> Can we assume Roboto is present (and the appropriate choice for sans-serif) on all devices?

For western languages, it seems so.

I remember one bug at least where with an issue about default CJK font
https://webcompat.com/issues/12400

the sans-serif selected for the Chinese character being different on different devices with 

body {
	font: 14px/1.7em "Helvetica Neue",Helvetica,"Heiti TC","Microsoft Sans Serif",Helvetica,Geneva,sans-serif;
}



Maybe a parallel issue which has impact on the layout in addition to Roboto is the default line-height.
on Android, is this still the case?
Default line-height:
* Firefox  1.1
* Chrome   1.2

Comment 22

[Jonathan Kew [:jfkthame]]

Tryserver (https://treeherder.mozilla.org/#/jobs?repo=try&revision=6fd8957245ce3980abeb5154c88868d89dae4bbc) says we'll need to check on a bunch of tests that are affected by this.

Mostly minor glyph positioning issues, and can probably just be annotated as fuzzy, but we should at least look at them. And on the bright side, there are also some existing failure annotations we can remove.

Comment 23

[Mike Taylor [:miketaylr]]

(Setting this to [webcompat:p1], due to its relationship to GWS Tier 1 and the number of dupes here.)

Comment 24

[James Willcox (:snorp) ([e-mail]) (he/him)]

Jonathan, are you going to try to land this? What are the plans?

Comment 25

[Jonathan Kew [:jfkthame]]

I think we should, but haven't had any spare cycles in the last few weeks to try and get it over the line. Basically, we just need to work through the failures (comment 22), and figure out what to do with each of them -- in most cases just annotate, I expect, but there could be exceptions to that.

Now that we're hitting code-freeze for 61, maybe I can get back to it.

Comment 26

[Maire Reavy [:mreavy]]

Jonathan is finishing up Variable Fonts, but the plan is for him to move onto this bug (a P1 webcompat bug) next.

Comment 27

[Jonathan Kew [:jfkthame]]

Pushed a new try run to see how things look (expecting at least a handful of test failures...):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5dfd15cc26b945a736b60af7a41cc378e1de3c7a

Comment 28

[Jonathan Kew [:jfkthame]]

Attachment: Use Roboto instead of Clear Sans as default sans-serif font on Android, for better webcompat

This removes the Clear Sans fonts and changes the relevant prefs/styling to use Roboto instead. I think we should go ahead and do this, so people can see the effect on the various webcompat issues related to font metrics/line spacing. The change affects a few tests, sometimes requiring more fuzz than previously, and sometimes less... the issues all look like minor pixel-rounding discrepancies, rather than significant bugs or real rendering failures.

Comment 29

[Jonathan Kew [:jfkthame]]

Attachment: Test/expectation adjustments for the change in default font on Android

I think this is everything needed to keep tests green (modulo the usual intermittents...). Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e065f270b79061fe33e54b8a4d49b111e8b8fc20.

Comment 30

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 8979454 [details] [diff] [review]
Test/expectation adjustments for the change in default font on Android

Review of attachment 8979454 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with nits addressed.

::: layout/base/tests/transformed_scrolling_repaints_3_window.html
@@ +27,5 @@
> +  t.contentWindow.scrollTo(0,0);
> +  utils = SpecialPowers.getDOMWindowUtils(window);
> +  iterations = 0;
> +
> +  waitForAllPaintsFlushed(nextIteration);

It would probably make the whole stuff clearer by rewriting it with async/await. Something like:
```javascript
async function runTest() {
  let t = document.getElementById("t");
  let e = t.contentDocument.getElementById("e");
  t.contentWindow.scrollTo(0,0);
  let utils = SpecialPowers.getDOMWindowUtils(window);

  for (let i = 0; i < 15; i++) {
    let painted = utils.checkAndClearPaintedState(e);
    if (i >= 5) {
      is(painted, false, "Fully-visible scrolled element should not have been painted");
    }
    t.contentWindow.scrollByLines(1);
    await promiseAllPaintsDone(null, true);
  }
  SimpleTest.finish();
  window.close();
}
```

::: layout/reftests/bugs/reftest.list
@@ +273,4 @@
>  == 244135-2.html 244135-2-ref.html
>  == 244932-1.html 244932-1-ref.html
>  == 246669-1.html 246669-1-ref.html
> +fuzzy-if(Android,255,114) == 249141.xul 249141-ref.xul

This doesn't look like fuzzy... There are several characters show up unexpectedly. Please mark it fail instead. (I'm not too worry about a xul test failing on Android so probably not worth filing a bug for it at all.)

::: layout/reftests/forms/legend/reftest.list
@@ +1,2 @@
>  == legend.html legend-ref.html
> +fuzzy-if(Android,255,41) == 1273433.html 1273433-ref.html

I don't see this in your try run, so it's not completely clear to me whether it's really a fuzzy... but it seems the number for difference is low enough for that test, so fine.

::: layout/reftests/w3c-css/submitted/flexbox/reftest.list
@@ +4,4 @@
>  == flexbox-abspos-child-002.html flexbox-abspos-child-002-ref.html
>  
>  # Tests for handling anonymous flex items
> +fuzzy-if(Android,225,116) == flexbox-anonymous-items-001.html flexbox-anonymous-items-001-ref.html

This test should probably be fixed rather than just add fuzzy. The testing area of this test seems to be small enough so that 116 feels like a non-trivial difference.

The failure seems to be related to kerning in the reference. Maybe we should fix the reference via wrapping "b b" in a inline-block <div> instead, and if that doesn't work... probably wrapping it in <span> and add some padding in both test and reference.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/415c8b8cbd17
Use Roboto instead of Clear Sans as default sans-serif font on Android, for better webcompat. r=xidorn
https://hg.mozilla.org/integration/mozilla-inbound/rev/e12f367e03e0
Test/expectation adjustments for the change in default font on Android. r=xidorn

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a63414fd3bef
followup, remove obsolete fuzzy() annotation that was inadvertently left in the patch. r=me

Comment 33

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/415c8b8cbd17
https://hg.mozilla.org/mozilla-central/rev/e12f367e03e0

Comment 34

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/a63414fd3bef

Comment 35

[Jonathan Kew [:jfkthame]]

Karl, this change should be in current Nightly builds; could you or others start looking over the various webcompat issues that we believe were related to the choice of font, and see whether we do see the expected improvements?

Comment 36

[Mike Taylor [:miketaylr]]

Sergiu, Oana, can y'all verify the fix on the linked webcompat issues? Thanks!

Comment 37

[Oana Arbuzov [:oanaarbuzov]]

We've re-tested all the "See Also" issues and bellow are the results:

https://webcompat.com/issues/9052 - Fixed
https://webcompat.com/issues/8386 - Fixed
https://webcompat.com/issues/8846 - Fixed
https://webcompat.com/issues/7326 - Fixed
https://webcompat.com/issues/8668 - Fixed
https://webcompat.com/issues/8621 - Fixed
https://webcompat.com/issues/8642 - Fixed
https://webcompat.com/issues/7516 - Fixed
https://webcompat.com/issues/9146 - Fixed
https://webcompat.com/issues/9182 - Fixed
https://webcompat.com/issues/6803 - Fixed
https://webcompat.com/issues/9601 - Fixed
https://webcompat.com/issues/13035 - Fixed
https://webcompat.com/issues/13030 - Fixed
https://webcompat.com/issues/13034 - Fixed
https://webcompat.com/issues/8068 - Fixed
https://webcompat.com/issues/8580 - Fixed
https://webcompat.com/issues/12392 - Fixed
https://webcompat.com/issues/12402 - Fixed
https://webcompat.com/issues/12765 - Fixed
https://webcompat.com/issues/12993 - Fixed
https://webcompat.com/issues/15394 - Reopened
https://webcompat.com/issues/15422 - Fixed
https://webcompat.com/issues/15459 - Fixed
https://webcompat.com/issues/15611 - Fixed
https://webcompat.com/issues/15585 - Reopened
https://webcompat.com/issues/17081 - Fixed
https://webcompat.com/issues/14343 - Fixed
https://webcompat.com/issues/16026 - Reopened
https://webcompat.com/issues/7016 - Reopened
https://webcompat.com/issues/7520 - Fixed
https://webcompat.com/issues/7593 - Unable to test ("Search" button doesn't work)
https://webcompat.com/issues/8071 - Fixed
https://webcompat.com/issues/14951 - Fixed
https://webcompat.com/issues/8638 - Fixed
https://webcompat.com/issues/14792 - Fixed
https://webcompat.com/issues/14864 - Fixed
https://webcompat.com/issues/12756 - Reopened
https://webcompat.com/issues/7984 - Unable to test (Blank page)
https://webcompat.com/issues/13777 - Reopened
https://webcompat.com/issues/10745 - Reopened
https://webcompat.com/issues/12725 - Fixed
https://webcompat.com/issues/14657 - Reopened
https://webcompat.com/issues/10388 - Fixed
https://webcompat.com/issues/14632 - Fixed
https://webcompat.com/issues/7858 - Reopened
https://webcompat.com/issues/6248 - Reopened
https://webcompat.com/issues/11739 - Fixed
https://webcompat.com/issues/16916 - Fixed
https://webcompat.com/issues/16912 - Fixed
https://webcompat.com/issues/16913 - Fixed
https://webcompat.com/issues/14051 - Fixed
https://webcompat.com/issues/12802 - Reopened
https://webcompat.com/issues/13921 - Fixed

Comment 38

[Mike Taylor [:miketaylr]]

Thanks Sergiu and Oana! Let's go ahead and verify this, with 43 / 54 being fixed by this patch. It looks like we need to better understand the other 11 -- they're not more broken than before (having looked at a few just now).