[Flame][2.1] latest nightly update changed fonts to something which looks like Courier New

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: smaug, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [SUMO-b2g])

Attachments

(1 attachment)

The new font is actually pretty easy to read, but I doubt it is the one we're supposed to have.
Depends on: 1032754
Offhand, it's not obvious to me what could be happening here. Screenshot, please? What exact build (gecko & gaia versions)?

Oh, one thought... :mwu, will the new fonts get installed via the usual nightly update process, or does something else need to happen there to get them onto people's devices?
Flags: needinfo?(mwu)
Looks like you're getting the Motoya font (Japanese), I'd guess.

I suspect the various font prefs - including the hard-coded fallback - got updated to "Fira Sans" (instead of the old "Fira Sans OT"), but you still have the older set of font files. So then the Fira family name doesn't match, and gecko ends up with whatever fallback it happens to find.

If you look in /system/fonts on the device, I'm guessing you'll find you've got FiraSansOT-*.otf fonts, which should have been replaced by the new FiraSans-*.otf set. I think this is a shortcoming of the update process, but I don't know anything about how that works or what we should be doing to address it.
And if I'm understanding this correctly, I don't think bug 1032754 is relevant; removing that dependency.
No longer depends on: 1032754
Blocks: Fira

Comment 5

5 years ago
Comment 3 is correct. Unfortunately, we had to change the name of the font *again*, so the new font has to be installed. If you're doing gecko/gaia only flashes, or rely on automatic updates, it won't update fonts. I put up a package at https://people.mozilla.org/~mwu/fira-font-update.zip to make font updating easier.
Flags: needinfo?(mwu)
(In reply to Michael Wu [:mwu] from comment #5)
> Comment 3 is correct. Unfortunately, we had to change the name of the font
> *again*, so the new font has to be installed. If you're doing gecko/gaia
> only flashes, or rely on automatic updates, it won't update fonts. I put up
> a package at https://people.mozilla.org/~mwu/fira-font-update.zip to make
> font updating easier.

Isn't OTA update support required here to actually ship this to users who upgrade their devices?

Comment 7

5 years ago
It depends on how the user upgrades their device. For automatic updates from our update infra, we need actual FOTA support.

Note that for actual updates on production devices, FOTA updates are the only updates at the moment, so this isn't a problem for production devices.
Blocks: 1034080

Updated

5 years ago
No longer blocks: 1034080
Hey Naoki, :mwu mentioned that you were was talking about having the new fonts included in new Flame base images to simplify things, is there an ETA on this? I believe that patch would resolve this bug.
Flags: needinfo?(nhirata.bugzilla)
Hi Patryk, 

That work has already been done with the flash tool as well as the OEM build.  See intranet page for OEM build, and https://github.com/Mozilla-TWQA/B2G-flash-tool/commit/8a5512c946bc7da34a1311281d1561730ba1a70c for the TWQA flash tool.

I haven't included it in my script.  I'm not sure how many people would need it when they can access the B2G-flash-tool's version.
Flags: needinfo?(nhirata.bugzilla)
naoki, so can we close this bug? As there is a resolution present.
Flags: needinfo?(nhirata.bugzilla)
I think so.  :smaug, what do you think?  Have you tried the new fonts?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(bugs)
I flashed the new fonts to the device and they work fine.
It was just a bit annoying to force to use flashing when one got used to nightly updates.
Flags: needinfo?(bugs)
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
I think the other thing is to get the vendor to add these fonts in the next oem build?
Since the fonts are Free Software and don't have kernel or hardware adaptation dependencies, it seems to me it would be more sense to make fonts part of the Gecko layer than the Gonk layer. Is there a reason not to do that? If not, is there already a bug for tracking moving the fonts from the Gonk layer to the Gecko layer for the purpose of updates?
Needinfoing nhirata for comment 14.
Flags: needinfo?(nhirata.bugzilla)
I am not sure of the complications behind that.  viral or mwu may know better.
Flags: needinfo?(vwang)
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(mwu)
(In reply to Henri Sivonen (:hsivonen) from comment #14)
> Since the fonts are Free Software and don't have kernel or hardware
> adaptation dependencies, it seems to me it would be more sense to make fonts
> part of the Gecko layer than the Gonk layer. Is there a reason not to do
> that? If not, is there already a bug for tracking moving the fonts from the
> Gonk layer to the Gecko layer for the purpose of updates?

In general, we want to move from doing Gecko level updates to Gonk level updates. This is how updates actually work for release phones and will let us do other things like ensure Gonk compatibility with the Gecko in the update.
Flags: needinfo?(mwu)

Updated

5 years ago
Flags: needinfo?(vwang)

Updated

4 years ago
Whiteboard: [SUMO-b2g]
For tracking purposes -
A user in the SUMO forums reported an issue related to this: https://support.mozilla.org/en-US/questions/1041960
You need to log in before you can comment on or make changes to this bug.