Closed Bug 1315752 Opened 3 years ago Closed 3 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox-esr45 --- affected
thunderbird_esr45 --- affected
thunderbird_esr52 ? ---
firefox50 --- affected
firefox51 --- wontfix
firefox52 --- fixed
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: Gijs, Assigned: jfkthame, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tpi:+][tpi-help-requested])

Attachments

(1 file, 1 obsolete file)

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
 .)
Blocks: sierra
Blocks: 1283573
I just tried creating a new Firefox profile, and still see the Missing font nag on starting FF with the new profile.
I'm on OS 10.12.1 (16B2555)
(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?
(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
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.
Priority: -- → P2
Whiteboard: tpi:+
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.
Continues to plague new version 50.0.
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)
Duplicate of this bug: 1322867
On Firefox 50.0.2 and Mac OS 10.12.1.  Created a new Firefox profile and still received download prompt.
Whiteboard: tpi:+ → [tpi:+][tpi-help-requested]
Keywords: helpwanted
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?
(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.
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.
just updated to thunderbird 45.7.0 under os x sierra 10.12.2 and still getting the download osaka font dialog too.
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.
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!
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
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
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/jkew@mozilla.com-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!
Just tidied up the patch a bit; functionally equivalent to the version in the tryserver build.
Attachment #8836704 - Flags: review?(mstange)
Attachment #8836688 - Attachment is obsolete: true
Attachment #8836688 - Flags: review?(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?
Flags: needinfo?(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.
Flags: needinfo?(jfkthame)
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
(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 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.
Attachment #8836704 - Flags: review?(mstange) → review+
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
https://hg.mozilla.org/mozilla-central/rev/f3dcd0723d35
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Too late for 51. Mark 51 won't fix.
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!
Flags: needinfo?(officialhut)
Flags: needinfo?(mhowie22)
Flags: needinfo?(iseevisions)
Flags: needinfo?(Norman.Shea)
Assignee: nobody → jfkthame
Flags: needinfo?(dorsetcr)
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!!
Flags: needinfo?(Norman.Shea)
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
Attachment #8836704 - Flags: approval-mozilla-esr52?
Attachment #8836704 - Flags: approval-mozilla-esr45?
Attachment #8836704 - Flags: approval-mozilla-beta?
Attachment #8836704 - Flags: approval-mozilla-aurora?
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+.
Attachment #8836704 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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-.
Attachment #8836704 - Flags: approval-mozilla-esr45? → approval-mozilla-esr45-
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.
Attachment #8836704 - Flags: approval-mozilla-esr52?
Attachment #8836704 - Flags: approval-mozilla-beta?
Attachment #8836704 - Flags: approval-mozilla-beta+
Tested on 2/20/17 TB 54.0a1 nightly, 10.12.3:  LGTM.
You need to log in before you can comment on or make changes to this bug.