Mac OS: whitelist the font .Helvetica Neue DeskInterface

In Mac OS 10.10 (Yosemite), the system font is .Helvetica Neue DeskInterface. But this is not included in font.system.whitelist in TB 5.5a4. Unless doing so will cause fingerprinting concerns, we should add it. I will attach a screenshot that shows that buttons do not look good without it.

added TorBrowserTeam201512R component::applications/tor browser owner::tbb-team parent::18097 priority::medium resolution::fixed severity::normal status::closed tbb-5.5 tbb-fingerprinting-fonts type::defect labels

Trac:

button comparison

Trac:
Keywords: N/A deleted, tbb-5.5, TorBrowserTeam201511 added

I guess my concern would be that whitelisting this font makes it straightforward to distinguish users of Yosemite from other OS X versions.

Is it possible to fix that button's height using CSS?

Trac:
Cc: N/A to arthuredelstein

I wonder what is making the button look odd. Has the previous UI font (Lucida Grande) been removed from 10.10? Maybe a different random font is being used because it is missing?

We could decide to accept that Yosemite is distinguishable, and whitelist that font. Is it a widespread problem in the UI?

Replying to arthuredelstein:

I wonder what is making the button look odd. Has the previous UI font (Lucida Grande) been removed from 10.10? Maybe a different random font is being used because it is missing?

Lucida Grande is still present. I don't know what font is being used on Yosemite. Is there a way I can find out? Computed CSS does not seem to provide the answer (it just lists "Helvetica Neue DeskInterface").

We could decide to accept that Yosemite is distinguishable, and whitelist that font. Is it a widespread problem in the UI?

It is a fairly widespread problem, although some buttons look OK; maybe those portions of the UI use a fixed height in CSS or XUL.

Is there any chance that text is being rendered using font A but metrics (e.g., height) are being derived from font B? The behavior Yawning saw in #17550 (moved) makes me suspicious - even if the wrong font is used, I would not expect the height to be such a mismatch for the rendered text.

Replying to mcs:

Replying to arthuredelstein:

I wonder what is making the button look odd. Has the previous UI font (Lucida Grande) been removed from 10.10? Maybe a different random font is being used because it is missing?

Lucida Grande is still present. I don't know what font is being used on Yosemite. Is there a way I can find out? Computed CSS does not seem to provide the answer (it just lists "Helvetica Neue DeskInterface").

For Firefox 38.0, I often use the two Firefox addons, DOM Inspector and Element Inspector. Then you can shift+right-click on the button and it opens a window showing information about the button. Then under the menubar, choose View > Object Viewer > Used Font Faces.

We could decide to accept that Yosemite is distinguishable, and whitelist that font. Is it a widespread problem in the UI?

It is a fairly widespread problem, although some buttons look OK; maybe those portions of the UI use a fixed height in CSS or XUL.

Is there any chance that text is being rendered using font A but metrics (e.g., height) are being derived from font B? The behavior Yawning saw in #17550 (moved) makes me suspicious - even if the wrong font is used, I would not expect the height to be such a mismatch for the rendered text.

That's a very good point. Yawning's bug is especially weird, because the element sizes go so badly wrong.

Replying to arthuredelstein:

For Firefox 38.0, I often use the two Firefox addons, DOM Inspector and Element Inspector. Then you can shift+right-click on the button and it opens a window showing information about the button. Then under the menubar, choose View > Object Viewer > Used Font Faces.

Thanks. Testing with the Page Info dialog (which has a "Save As..." button on the "Media" tab), Kathy and I had to "walk up the tree" a little before anything was displayed in the "Object - Used Font Faces" area. When we get to the grandparent element (an hbox), the Used Font Faces area shows "Helvetica". I am not sure why that font is selected, but I guess some code is substituting plain "Helvetica" for ".Helvetica Neue DeskInterface". I do not know if that is expected or not.

It seems like Helvetica just looks bad in some situations. When we add style="font-face: Helvetica" via DOM Inspector in Firefox 43 beta and see the same rendering problem. If we add style="font-face: Lucida Grande" it looks fine. How difficult is it to control which font is substituted when a font is not available?

Trac:
Keywords: N/A deleted, tbb-fingerprinting-fonts added
Cc: arthuredelstein to arthuredelstein, gk

Trac:
Keywords: TorBrowserTeam201511 deleted, TorBrowserTeam201512 added

I posted a fix to https://github.com/arthuredelstein/tor-browser/commits/17250+1. This branch also contains a second patch for #17250 (moved).

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201512 deleted, TorBrowserTeam201512R added

r=mcs This fixes the problem for me (tested under Mac OS 10.10.5).

Alright, this makes it into 5.5a5, thanks. (commit 7cda561f125169f05a539be1b5afd88522d4fc46 on tor-browser-38.4.0esr-5.5-1)

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Trac:
Parent: N/A to 18097

Trac:
Parent: 18097 to #18097 (moved)

closed

mentioned in issue #18097 (moved)

moved to tpo/applications/tor-browser#17661 (closed)

mentioned in issue tpo/applications/tor-browser#18097 (closed)