1315752 - [10.12 / sierra] Investigate continued prompts to download Osaka (from plugin-container / new tab page / ... others?)

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[:Gijs (out for now; he/him)]

Splitting off from bug 1283573 where this was previously fixed. I've CC'd everybody who reported still seeing this.

As a very basic check, can anyone reproduce this if they recreate a new Firefox profile? (you can keep your current profile, see https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles for instructions)

(I'm on 10.12, I still see this prompt on old versions of Gecko including e.g. Thunderbird, and a copy of ChatZilla running on an old copy of xulrunner, but never in Firefox (50 beta). I just tried running a clean new profile on 50 beta and couldn't reproduce that way either. Osaka appears in my Font Book, but both it and its regular and mono variants are greyed out. The only hit for the 'find' command in bug 1283573 is /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Support/FontSubsets/Osaka.ttf
 .)

Comment 1

[B]

I just tried creating a new Firefox profile, and still see the Missing font nag on starting FF with the new profile.

Comment 2

[B]

I'm on OS 10.12.1 (16B2555)

Comment 3

[:Gijs (out for now; he/him)]

(In reply to B from comment #1)
> I just tried creating a new Firefox profile, and still see the Missing font
> nag on starting FF with the new profile.

Is your sierra install brand new or an upgrade from 10.10 / 10.11 / something else?

Comment 4

[B]

(In reply to :Gijs Kruitbosch from comment #3)
> (In reply to B from comment #1)
> > I just tried creating a new Firefox profile, and still see the Missing font
> > nag on starting FF with the new profile.
> 
> Is your sierra install brand new or an upgrade from 10.10 / 10.11 /
> something else?

It is an upgrade from 10.11

Comment 5

[Howie]

Upgrade from 10.11 for me as well. Any new tab opening prompts this annoying bug/message. Probably not a contributor but I have Tab Mix Plus installed.

Comment 6

[officialhut]

Fresh install of macOS 10.12. Firefox 49.0.2.

I tried a new profile, but got the exact same result, with a dialog box saying "plugin-container needs to download the font “Osaka”".

Initially, this seemed to be related to new tabs with the selection of recent/frequent sites. But, I cleared that list, and still get the dialog box.

Comment 7

[Howie]

Continues to plague new version 50.0.

Comment 8

[John Hesling [:John99] (NeedInfo me)]

Any particular information that we should ask those who are able to reproduce this issue ?
The issue is also reported on Sumo & we have a tracking thread 
https://support.mozilla.org/forums/support-forum-contributors/712316
I have also tagged some of the individual threads
https://support.mozilla.org/questions/firefox?owner=all&tagged=bug1315752&show=all

(Sumo fora migrate to Lithium Software anytime soon, and I am not sure whether such links will then redirect properly)

Comment 10

[Norm Shea]

On Firefox 50.0.2 and Mac OS 10.12.1.  Created a new Firefox profile and still received download prompt.

Comment 11

[Norm Shea]

Sorry, new to this process.  What do Stephen A Pohl's post
"Whiteboard: tpi:+ → [tpi:+][tpi-help-requested]"

and 

Gijs' post
"Keywords: helpwanted"

mean?  Is that directed at Mozilla programmers?

Comment 12

[:Gijs (out for now; he/him)]

(In reply to Norm Shea from comment #11)
> Sorry, new to this process.  What do Stephen A Pohl's post
> "Whiteboard: tpi:+ → [tpi:+][tpi-help-requested]"
> 
> and 
> 
> Gijs' post
> "Keywords: helpwanted"
> 
> mean?  Is that directed at Mozilla programmers?

At pretty much anyone who has more information about why this happens on some machines and not others, ideally of the kind where it's possible for Markus or someone else who knows this code to reproduce the problem. Without being able to reproduce or understanding why this is happening, it's almost impossible to fix.

Comment 13

[Kris Lou]

This also appears when creating a new profile (aka first launch) of Thunderbird 45.6+ (including the newly released 45.7) on Sierra.  10.12.2-3.

Comment 14

[kautzy]

just updated to thunderbird 45.7.0 under os x sierra 10.12.2 and still getting the download osaka font dialog too.

Comment 15

[:Gijs (out for now; he/him)]

I think this affecting Thunderbird 45 is expected - bug 1283573 was only fixed in 48, and not backported to ESR, on which Thunderbird 45 is based. It will be fixed in Thunderbird 52.

Comment 16

[Jonathan Kew [:jfkthame]]

For someone who is seeing this problem with a current version of Firefox (not Thunderbird 45.x - see comment 15):

Could you please attach a copy of the file /System/Library/Assets/com_apple_MobileAsset_Font3/com_apple_MobileAsset_Font3.plist for us to check, together with details of how the Osaka font(s) show up (if at all) in Font Book on your system: do you have both the "Regular" and "Regular-Mono" faces, only one of them, or no Osaka at all; and are they grayed out or normal?

Thanks!

Comment 17

[Marco Mueller]

I am not very experienced taking part in these bugtracker discussions but as far as I am facing this bug too I try my best to give some informations.

I am using macOS 10.12.2 with Firefox 51.0.1 (update channel release) and Thunderbird 45.7.1 (update channel release).

I am facing this Osaka-download message while starting Thunderbird. Never seen this while starting Firefox at all.

Today I wanted to see how it works with any beta version of Thunderbird, so I decided to download and install it parallel to my version. On the web page I found Thunderbird 52.0b2. This version seems to use the existing profile and wow, it starts without the Osaka-download message.

I don't know if this information was helpful but I thought reporting a version which seems not affected for me could be interesting.

I try to attach my com_apple_MobileAsset_Font3.plist after posting this.

Regards
Marco

Comment 18

[Marco Mueller]

Oh, I just realized the file is just needed from someone who is facing this with Firefox. So I am the wrong one and don't attch my file. Sorry for my misunderstanding.

Regards
Marco

Comment 19

[Jonathan Kew [:jfkthame]]

I've been sent the .plist file and other info requested from an affected machine by private email, and I think I understand what's happening sufficiently to propose a fix here.

There's a patched Nightly build available at:
https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-fc3bd0e0175c65da42f57815b2b762b47170f9e0/try-macosx64/firefox-54.0a1.en-US.mac.dmg
If people who are currently seeing this issue with Firefox could test that version and confirm whether the problem still occurs (though I don't think it will), that would be really helpful - thanks!

Comment 20

[Jonathan Kew [:jfkthame]]

Attachment: Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

Comment 21

[Jonathan Kew [:jfkthame]]

Attachment: Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

Just tidied up the patch a bit; functionally equivalent to the version in the tryserver build.

Comment 22

[Markus Stange [:mstange]]

Thanks you for debugging this! I don't understand the problem or the solution though. Could you explain what was triggering the dialog, and how the patch is avoiding it? Is it something about the separate font entry with a different family name?

Comment 23

[Jonathan Kew [:jfkthame]]

The issue is that with Osaka becoming a downloadable asset rather than a universally pre-installed font, it's possible for a user's system to be in a state where the Osaka-Regular face is present (and therefore the Osaka family shows up in the main font family list), but Osaka-Mono has still not been downloaded. Until recently, I wasn't aware that the family could be in that partially-installed state, but apparently it does happen (perhaps depending on how the download was originally triggered).

The download prompt then occurs when we use LookupLocalFont() to find the Osaka-Mono face, because that calls CGFontCreateWithFontName, which is aware of the downloadable font assets; so when it is asked for Osaka-Mono, and sees that it hasn't been downloaded, it offers to help out.

We tried to avoid this by checking for the presence of the Osaka family before calling LookupLocalFont(), and that solved things for most users (where the Osaka family was either fully installed or not installed at all), but it fails in the case where the Regular face is present but Mono isn't.

So this patch works around that by avoiding LookupLocalFont (and therefore CGFontCreateWithFontName) altogether, and instead searching the faces actually present in the main Osaka family. If Osaka-Mono is installed, it will be found there and we can then duplicate its font entry and create the separate Osaka-Mono family; and if not, we safely (and silently) ignore it.

Comment 24

[Kris Lou]

In response to Wayne's request for testing (to TB-enterprise), this bug still affects TB 52.0b2 on 10.12.3

I've removed all external traces to Osaka.ttf from my test machine (/Library/Fonts, /Network/Library/Fonts) and removed the local TB profile before testing.  Osaka still exists in the Fontbook (OsakaMono is downloadable), and at /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Support/FontSubsets/Osaka.ttf

Comment 25

[Jonathan Kew [:jfkthame]]

(In reply to Kris Lou from comment #24)
> In response to Wayne's request for testing (to TB-enterprise), this bug
> still affects TB 52.0b2 on 10.12.3
> 
> I've removed all external traces to Osaka.ttf from my test machine
> (/Library/Fonts, /Network/Library/Fonts) and removed the local TB profile
> before testing.  Osaka still exists in the Fontbook (OsakaMono is
> downloadable), and at
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/
> Frameworks/ATS.framework/Versions/A/Support/FontSubsets/Osaka.ttf

Yes, this scenario (the Regular face of Osaka is installed, but Osaka-Mono is shown as a downloadable resource) is exactly where Firefox users are also still seeing this problem. The patch just posted here today should fix this (for both FF and TB) once it makes its way into builds.

Comment 26

[Markus Stange [:mstange]]

Comment on attachment 8836704 [details] [diff] [review]
Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

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

Thanks for the explanation, that makes sense. It's probably worth putting comment 23 verbatim into the commit message.

Comment 27

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f3dcd0723d358412c1b5e14e7b20319a10966475
Bug 1315752 - Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt. r=mstange

Comment 28

[Carsten Book [:Tomcat]]

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

Comment 29

[Gerry Chang [:gchang]]

Too late for 51. Mark 51 won't fix.

Comment 30

[Jonathan Kew [:jfkthame]]

To those who have been seeing this issue with a current Firefox release: please try the latest Firefox Nightly (from https://nightly.mozilla.org/) and confirm whether the Osaka-download prompt has finally been eliminated. Thanks!

Comment 31

[Norm Shea]

I downloaded and installed Nightly 54.0a1 (2017-02-16) and I'm cautiously optimistic. In Firefox 51.0.1, I just a minute ago opened a new tab and promptly got the Osaka popup.  Closed Firefox and booted Nightly, restored previous session and opened a new tab and......NO Osaka popup!!  Woohoo!!  I've opened additional new tabs and still no popup.  I think you did it! That's fantastic and thank you so much!!

Comment 32

[Jonathan Kew [:jfkthame]]

Comment on attachment 8836704 [details] [diff] [review]
Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: This fixes a highly visible irritant for affected users, who cannot understand why they are nagged about downloading a Japanese font when they launch Firefox.

User impact if declined: Continued prompts about downloading Osaka font for some macOS users

Fix Landed on Version: 54

Risk to taking this patch (and alternatives if risky): low risk; Mac-only code, so cannot affect other platforms; this code is used only to set up a single special-case Japanese font family, so even if we broke it entirely, the impact would be minor

String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Approval Request Comment
[Feature/Bug causing the regression]: macOS Sierra made some system font resources have download-on-demand behavior

[User impact if declined]: highly visible irritation for affected users

[Is this code covered by automated tests?]: no, we don't have macOS Sierra systems running in automation

[Has the fix been verified in Nightly?]: yes

[Needs manual test from QE? If yes, steps to reproduce]: no

[List of other uplifts needed for the feature/fix]: none

[Is the change risky?]: no

[Why is the change risky/not risky?]: Mac-only code, so cannot affect other platforms; this code is used only to set up a single special-case Japanese font family, so even if we broke it entirely, the impact would be minor

[String changes made/needed]: none

Comment 33

[Gerry Chang [:gchang]]

Comment on attachment 8836704 [details] [diff] [review]
Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

Fix a download font resources pop-up issue in Sierra and was verified. Aurora53+.

Comment 34

[Gerry Chang [:gchang]]

Comment on attachment 8836704 [details] [diff] [review]
Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

For ESR45, this doesn't match the esr criteria (only sec-high & sec-critical issues). ESR45-.

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6e46b6455cae

Comment 36

[Julien Cristau [:jcristau]]

Comment on attachment 8836704 [details] [diff] [review]
Avoid using LookupLocalFont to find the Osaka-Mono face in InitSingleFaceList, so we don't risk triggering a font-download prompt

avoid prompt on osx 10.12, beta52+

Clearing approval flag for esr52, that branch is kept in sync with beta until the 52 release.

Comment 37

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/398b16c6ce7a

Comment 38

[Kris Lou]

Tested on 2/20/17 TB 54.0a1 nightly, 10.12.3:  LGTM.

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/398b16c6ce7a