1196325 - Fonts have changed from Arial to Segoe UI

Status: UNCONFIRMED

(Core :: Graphics: Text, defect)

Description

[u547265]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150812163655

Steps to reproduce:

As I was on Wikipedia (or any other site that has these elements) I noticed some of the buttons and dropdowns looked different. Started happening from Firefox 40, was fine on 39. See below for details.


Actual results:

The fonts had changed from Arial to Segoe UI for certain buttons, text fields or dropdowns.


Expected results:

Firefox on right, IE and Chrome on left: https://i.imgur.com/H9J3Wg0.png  -  Additional buttons in Segoe UI in Firefox, and like normal in Arial elsewhere: https://i.imgur.com/lChz4I5.png. FF39 vs FF40 of the same element (note, it should be using Arial): https://i.imgur.com/x6UyatC.png -- Other people have confirmed this issue at http://redd.it/3gpa4l.

Comment 1

[:Gijs (he/him)]

I expect this is caused by 1123654, but I don't know for sure. Jonathan?

Comment 2

[Jonathan Kew [:jfkthame]]

Yes, I expect this is a result of bug 1123654. Given that Segoe UI is the default Windows UI font, it seems pretty reasonable for it to be used for buttons, no?

If authors specifically want buttons in Arial (for example), they can style them with font-family:Arial to achieve this. Otherwise, the default styling of these and other form controls may well vary across platforms, browser versions, etc. (E.g. on Mac, I expect they'll default to one of Lucida Grande or Helvetica Neue or San Francisco, depending on the OS X version.)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is this effectively fixed by the fix for bug 1194055?

Comment 4

[Jonathan Kew [:jfkthame]]

Probably not. I believe we'll currently get Tahoma for those buttons, etc., by default, which seems like a perfectly reasonable default (IMO) but doesn't match the Arial that the OP wanted.

FWIW, prior to bug 1123654 we did NOT actually use Arial for those elements; we were using Microsoft Sans Serif. Which for basic Latin text looks virtually indistinguishable from Arial, but has some significant limitations -- e.g. no true bold face, and the almost-illegible ellipsis glyph that prompted bug 1123654 in the first place.

I'm inclined to consider this bug as invalid, as I don't think there is any legitimate reason to expect the font used by default in form controls to look like Arial. The fact that it used to (on Windows) was a result of the legacy API we were using. We've switched to newer Windows APIs, and now we get Tahoma by default; that's the expected result of the update. The exact rendering of form controls is in general unspecified, and will vary significantly between platforms and browsers.

So my suggestion is to resolve as invalid (or wontfix), but I'll leave this open for further comments or opinions for now.....

Comment 5

[fernando.ferreira]

(In reply to Jonathan Kew (:jfkthame) (PTO - back Sept 1st) from comment #2)
> Yes, I expect this is a result of bug 1123654. Given that Segoe UI is the
> default Windows UI font, it seems pretty reasonable for it to be used for
> buttons, no?
> 
> If authors specifically want buttons in Arial (for example), they can style
> them with font-family:Arial to achieve this. Otherwise, the default styling
> of these and other form controls may well vary across platforms, browser
> versions, etc. (E.g. on Mac, I expect they'll default to one of Lucida
> Grande or Helvetica Neue or San Francisco, depending on the OS X version.)

Greetings. After noticing the same behaviour I filled bug 1199140 misinterpreting it as if form elements used to inherit from body instead of having the Arial look alike as the default font. It was correctly closed as invalid.

Also, the proposed fix works and it is the correct way to style form element, explicitly instead of implicitly if the author desires to control the exact look of the elements.

However this change in behaviour can be a problem to a multitude of legacy websites as "Arial, Helvetica, sans-serif" was a very popular web safe font family combo and also for sites that used simply "sans-serif" as the default body font family. 

My theory (uncorroborated) is that in the past the belief that the body style were inherited by form elements was widespread and, coincidentally, the form element default font family happened to be (a very similarly lookalike of) Arial causing the authors to believe that the font family they explicitly set in the body tag would be inherited by the form elements. 

This change will cause a lot of websites to break (in the worst case) or to become uglier by having a mismatched font family between text and form elements (in the bestI) due to that incorrect assumption. 

Is it possible that the desired effect of the change done at the bug 1123654 -- to use the Windows default font for form elements -- will cause more adverse effects than benefits? It is my belief that it will.

It seems that the old behaviour (Arial or its lookalike in the form elements) is the one happening right now on Google Chrome and even on Microsoft's own Internet Explorer (at least on IE11 on Windows 7). I don't really know if it is because their default stylesheet uses font-family: Arial (I believe that's the case for Chrome) or font-family: sans-serif (the default on IE, according to http://www.iecss.com/) but even in the latest versions on those browsers the appearance of the form elements do not seems to have changed. Only on Firefox this behaviour have suddenly changed without page authors interference.

My proposal is that this bug do not get closed as invalid or wontfix, that the changes that led Segoe UI to be used as the default form element font get reverted and that the original bug that motivated this change get fixed using an alternative method that do not change legacy pages.