Closed Bug 1319079 Opened 8 years ago Closed 7 years ago

Fonts inconsistency on Linux

Categories

(DevTools :: General, defect, P2)

Product:
DevTools
Component:
General
Platform:
Unspecified
Linux
Type:
defect

Tracking

(firefox53 fixed)

Status:
RESOLVED FIXED
Milestone:
Firefox 53
Tracking Flags:
Tracking Status
firefox53 --- fixed

People

(Reporter: pbro, Assigned: kpennington)

References

Details

Attachments

(8 files, 2 obsolete files)

Linux DevTools, font-size = 80%
54.48 KB, image/png
Details
Linux DevTools, font-size = 100%
62.85 KB, image/png
Details
1319079-rebased.patch
1.92 KB, patch
Details | Diff | Splinter Review
screenshot of Inspector in rv50 on a non-Gnome 120DPI Linux installation
157.62 KB, image/png
Details
firefox-dev-monospace-fonts.png
278.51 KB, image/png
Details
screenshot of Inspector in rv53 on a non-Gnome 120 DPI Linux installation
179.97 KB, image/png
Details
screenshot of Inspector in rv53 on a Debian Jessie/TDE 143 DPI installation
168.84 KB, image/png
Details
Screenshot Dev edition vs Nightly on KDE/Debian Sid 84 DPI
411.01 KB, image/png
Details 
I've seen 2 reports of fonts looking weird in devtools on Linux:

https://twitter.com/rahilwazir/status/800715777682903040/photo/1

The issue here is that, using the Firebug theme, the font-size between the markup-view and the rule-view seem to differ. Maybe the font-family too. Also, the breadcrumbs font-size seems bigger than the rest.

https://twitter.com/fvsch/status/796365775749652480

The issue here is that the font-size in the UI (in the tabs for instance) is fine, but the font-size inside the code editor is too small in comparison. Just zooming-in devtools is therefore not an option, because while that would make the code more readable, it would also make the UI elements just too big.

I think we need someone with a Linux distro to spend some time making CSS theme adjustments to make sure things look good. Right now they don't.
I'd like to work on this bug.
(In reply to Kimberly Pennington [:kimberlythegeek] from comment #1)
> I'd like to work on this bug.
Thanks for wanting to fix this!
If you haven't already, you will want to read through our contribution guide: https://developer.mozilla.org/en-US/docs/Tools/Contributing
I think :bgrins might be a good person to help figuring out which files would need changing here. I've needinfo'd him here.
Flags: needinfo?(bgrinstead)
Thanks; I've been looking at the code and I've found (at least part of) what's causing it.

In the devtools/client/css/common.css file there is this line:

:root[platform="linux"] .devtools-monospace {
  font-size: 80%;
}

I am running linux, and confirm that this only happens in the Firebug theme; the font sizes in the dark and light themes are consistent.

I suspect that, somewhere, there is CSS causing this discrepancy, but I don't know enough about the tools or structure to pinpoint it.

But, the easiest and quickest way would be to reset the font-size to 100% in the firebug-theme.css file
I found it :)

There is a place in the Firebug theme that sets the ruleview font size to 11px, but not that of the inspector.

.theme-firebug .ruleview {
    font-family: monospace;
    font-size: 11px;
}

My opinion is to remove both that and the 

:root[platform="linux"] .devtools-monospace {
  font-size: 80%;
}

rule, because at 80% it is a bit small for easy readability. Attaching screenshot for reference
(In reply to Kimberly Pennington [:kimberlythegeek] from comment #4)
> I found it :)

Nice.

> My opinion is to remove both that and the 
> 
> :root[platform="linux"] .devtools-monospace {
>   font-size: 80%;
> }
> 
> rule [...]

I don't know this code, but the next step would be to write a patch and try it out.
There are some rather voluminous instructions here: https://wiki.mozilla.org/DevTools/Hacking
but if you've already done a build you can skip ahead to the patch instructions:
https://wiki.mozilla.org/DevTools/Hacking#Making_and_Submitting_a_Patch
I'd suggest using "r?bgrins" as he's good person to review this.
(In reply to Tom Tromey :tromey from comment #7)

> I don't know this code, but the next step would be to write a patch and try
> it out.
> There are some rather voluminous instructions here:
> https://wiki.mozilla.org/DevTools/Hacking
> but if you've already done a build you can skip ahead to the patch
> instructions:
> https://wiki.mozilla.org/DevTools/Hacking#Making_and_Submitting_a_Patch
> I'd suggest using "r?bgrins" as he's good person to review this.


Thanks! I have done the build (voluminous indeed...); I'll get started reading about patches.
There's been a discussion in Bug 900173 about the 80% sizing - it seems in certain systems the 100% is too big, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=900173#c18.

That said, I think the 80% being applied to devtools-monospace is causing inconsistent results across the tools and I'd be happy to get this landed (and dupe Bug 900173 to this).  If this still makes the Ubuntu font huge then maybe we should pick an explicit monospace font instead of using the system font.  I'll check with the patch applied.
Flags: needinfo?(bgrinstead)
Assignee: nobody → email
Status: NEW → ASSIGNED
(In reply to Brian Grinstead [:bgrins] from comment #10)
> There's been a discussion in Bug 900173 about the 80% sizing - it seems in
> certain systems the 100% is too big, for example:
> https://bugzilla.mozilla.org/show_bug.cgi?id=900173#c18.


Ahh. In that screenshot, the font size on the left is larger. The rule view font size is set to 11px, so instead of removing the font-size: 80% for linux, I can just set it to 11px.
Comment on attachment 8817690 [details]
Bug 1319079 - Fonts inconsistency on Linux

https://reviewboard.mozilla.org/r/97906/#review98364

::: devtools/client/themes/common.css:23
(Diff revision 1)
>    --monospace-font-family: Consolas, monospace;
>  }
>  
>  :root[platform="linux"],
>  :root.theme-firebug {
>    --monospace-font-family: monospace;

If you set font-size: 11px here, does it look right for you?
(In reply to Brian Grinstead [:bgrins] from comment #12)
> Comment on attachment 8817690 [details]
> Bug 1319079 - Fonts inconsistency on Linux
> 
> https://reviewboard.mozilla.org/r/97906/#review98364
> If you set font-size: 11px here, does it look right for you?

Yes. It seems that 11px may be the default for my distro. 11px = 100% for me.
(In reply to Kimberly Pennington [:kimberlythegeek] from comment #13)
> (In reply to Brian Grinstead [:bgrins] from comment #12)
> > Comment on attachment 8817690 [details]
> > Bug 1319079 - Fonts inconsistency on Linux
> > 
> > https://reviewboard.mozilla.org/r/97906/#review98364
> > If you set font-size: 11px here, does it look right for you?
> 
> Yes. It seems that 11px may be the default for my distro. 11px = 100% for me.

OK, that sounds good to me.  Let's do 11px on :root in linux / firebug and keep your existing changes in this patch
Comment on attachment 8817690 [details]
Bug 1319079 - Fonts inconsistency on Linux

https://reviewboard.mozilla.org/r/97906/#review98368

Thanks!  Tested locally with these patches on Ubunutu and the issue I was seeing in Bug 900173 isn't a problem anymore
Attachment #8817690 - Flags: review?(bgrinstead) → review+
Comment on attachment 8818041 [details]
font sizes was set to 80% because they appear larger on some linux distros

https://reviewboard.mozilla.org/r/98166/#review98370
Attachment #8818041 - Flags: review?(bgrinstead) → review+
Unlucky timing - this needed to be rebased on top of Bug 1318259 (https://hg.mozilla.org/integration/mozilla-inbound/rev/285af284df45). 

A similar solution was added, so I just replaced the lines they added:

:root[platform="linux"].theme-firebug .devtools-monospace {
  font-size: 11px; /* Font becomes too small for linux with 80% */
}

With what you added:

:root[platform="linux"] .devtools-monospace {
  font-size: 11px;
}
Attachment #8817690 - Attachment is obsolete: true
Attachment #8818041 - Attachment is obsolete: true
See Also: → 1318259
How is 'font-size: 11px' supposed to be in any way usable on elevated DPI systems where the system font happens to work out to e.g. 20px (10pt@144DPI) and the browser default is e.g. 24px? Font sizing via CSS should never be in px, instead, always relative to user and/or system settings, whatever they happen to be. 11px is always unreadable here, and worse when not 'font-color: #000' on a light background, as is rampant in Mozilla's tools and web pages.
(In reply to Felix Miata from comment #20)
> How is 'font-size: 11px' supposed to be in any way usable on elevated DPI
> systems where the system font happens to work out to e.g. 20px (10pt@144DPI)
> and the browser default is e.g. 24px? Font sizing via CSS should never be in
> px, instead, always relative to user and/or system settings, whatever they
> happen to be. 11px is always unreadable here, and worse when not
> 'font-color: #000' on a light background, as is rampant in Mozilla's tools
> and web pages.

From the section here https://www.w3.org/Style/Examples/007/units.en.html#font-size:

"The px unit thus shields you from having to know the resolution of the device. Whether the output is 96 dpi, 100 dpi, 220 dpi or 1800 dpi, a length expressed as a whole number of px always looks good and very similar across all devices."

This change was made because 80% is too small for the system font in some cases, but 100% was too big in other cases (Bug 900173, Bug 1318259).  11px should work across any dpi but please share a screenshot if you are seeing otherwise.
(In reply to Brian Grinstead [:bgrins] from comment #21)

> From the section here
> https://www.w3.org/Style/Examples/007/units.en.html#font-size:
 
> "The px unit thus shields you from having to know the resolution of the
> device.

That information in virtually all cases would be irrelevant, if designers were embracing the environment they find themselves in generally, as when rem units are the primary or sole font sizing specification. Done thus there's nothing to be shielded from.

> Whether the output is 96 dpi, 100 dpi, 220 dpi or 1800 dpi, a length
> expressed as a whole number of px always looks good and very similar across
> all devices."

That spec is theoretical hogwash, not the real world. In the real world, people need what they need, not what some arbitrary engineer's specification says they are supposed to be content with. I have a whole building full of different size, density and aspect ratio displays, and hundreds of (overwhelmingly Linux) operating system installations in various DE configurations. It's rarely the case that anything web-related and sized in CSS px doesn't need to be increased from the way it's initially presented, Mozilla products being a prime offender.
 
> This change was made because 80% is too small for the system font in some
> cases,

Lest we forget, if we've ever been taught in the first place, 80% of anything in CSS is a length, not a size. 80% in height is also 80% in width, and size is a function of both height and width. 80% in CSS really means 64% in size, or 36% smaller than the presumptive optimal 100%, whatever that size in px may be. And, % is applied to the parent, which also may be a fraction of a parent, which in turn may be a fraction of another parent, and so on. To do theming right in most cases, both px and % should be for the most part dispensed with, and rem units used in their places, if and when it's not appropriate to use system, 1rem, 1em or 100% in the first place.

When the system font is called, the system font should be used, not some arbitrary fraction thereof, except in limited circumstances, especially not as small as 80%, and certainly not some px value that has no predictably positive correlation to the configured system size (which is virtually always in genuine if typically inaccurate pt units).

> but 100% was too big in other cases (Bug 900173, Bug 1318259).  11px
> should work across any dpi but please share a screenshot if you are seeing
> otherwise.

Besides this attachment, here's another fairly recent screenshot:
https://bug757142.bugzilla-attachments.gnome.org/attachment.cgi?id=333554
Its cause, which is WONTFIX, resulted in WONTFIX'd bug 1269274 where you can see similar Mozilla font size trouble. If these shots are insufficient, please provide more specifically what it is you wish to see.
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a1c8a9bc7ebc
Fix fonts inconsistency on Linux;r=bgrins
Keywords: checkin-needed
(In reply to Felix Miata from comment #22)

I apologize that this fix doesn't work for you. We are trying find a solution that works for everyone, which you seem to be aware is not always as simple as it seems. Please feel free to suggest an alternative.

Thank you for your input.
https://hg.mozilla.org/mozilla-central/rev/a1c8a9bc7ebc
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
(In reply to Felix Miata from comment #22)
> Besides this attachment, here's another fairly recent screenshot:
> https://bug757142.bugzilla-attachments.gnome.org/attachment.cgi?id=333554
> Its cause, which is WONTFIX, resulted in WONTFIX'd bug 1269274 where you can
> see similar Mozilla font size trouble. If these shots are insufficient,
> please provide more specifically what it is you wish to see.

It would be helpful if you could send a screenshot of a build with this patch applied for comparison with your screenshot from 50.  This will be in a Nightly build tomorrow, or can be built now using a local mozilla-central checkout.
Hi, everyone. Mike Hoye here, Mozilla's engineering community manager. 

As you might expect, our engineers have a great deal of discretion about how to best spend their time, and a bug full of toxic comments is not something anyone looks forward to touching at all, much less moving to the top of their priority queue.

This is your less-than-gentle reminder that Bugzilla is our professional working environment as much as it is our issue tracker, and the fact that we value and encourage community involvement in Firefox development does not give anyone the right to patronize or demean our colleagues. No single contributor’s work outweighs the importance of civility and professionalism among Mozillians as developers and as part of our community, and aggressive, passive-aggressive or hostile comments directed at our colleagues are not acceptable. 

If you can't find a way to participate productively in this bug without demeaning other Mozilla community members, their responses or their work, then don't. If you decide to do so anyway, my next step will be deactivating your bugzilla account. 

If you've got questions about that, feel free to email me directly. 

Have a good week.
Hey Guys,

I worked on the Bug#1318259 :) . The issue (screenshot) was that of the firebug theme which is under going  a makeover (bug#1314919) . However by making the font-size:11px on line 35 (git-id: 7ae5a18) (../client/themes/common.css); We've made the light and dark theme fonts too at 11px, Which looks small!

Shouldn't the fonts be relative, 'cause on a Big screen, 11px would be really tiny. Ideas?
Flags: needinfo?(pbrosset)
(In reply to Ruturaj Vartak from comment #28)

This was my original suggestion, but it seems that the setting of 100% / 1em is too large on some distros.

Anyone happen to know what distribution(s) this occurs in?

I use Linux Mint; I assume (perhaps erroneously) that it would be the same in all Debian systems.
(In reply to Kimberly Pennington [:kimberlythegeek] from comment #29)
> ...it seems that the setting of 100% / 1em
> is too large on some distros.
> Anyone happen to know what distribution(s) this occurs in?
> I use Linux Mint; I assume (perhaps erroneously) that it would be the same
> in all Debian systems.

As there are so many Debian variants, I don't believe any such assumption reasonable.

Just making an educated speculation here that the involvement of Xft.dpi could be at the root of such reports. Xft.dpi with a non-null initial value is generally a wholly unnecessary redundance in Xorg, as the server itself forces logical DPI to 96 (to emulate Windows) unless overridden by a global Xorg configuration setting or the use of xrandr in startup, or overridden by GTK3. 

Xft.dpi is used to force DPI via KDE's and TDE's user settings, while it's null in KDE and TDE otherwise - unless set globally by the distro's default configuration, or by GTK3. Some distros set Xft.dpi globally, always to 96 (e.g. both Fedora and Mandriva set it in /etc/X11/Xresources), while others don't (among them openSUSE and possibly Debian). IIRC, as I'm never a Gnome user, Xft.dpi is used by Gnome and other DEs (e.g. XFCE?) to set individual users' small/medium/large/xlarge (aka zoom) UI level. Post version 3.16, GTK3 forces Xft.dpi:96 into the environment if it finds it to be null[1]. 

When Xft.dpi is set, it's possible in some DEs for some apps to experience a different logical desktop DPI than other apps. I remember at least once I was able to have three different DPI reporting tools report unique values simultaneously.

Use 'xrdb -query | grep dpi' to discover if Xft.dpi is set.

[1] https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f
cf. https://bugs.kde.org/show_bug.cgi?id=367499 and bug 1319079
Given how unreadable it used to be at 80% in some systems (this bug and bug 900173), I'm happy with the solution in this bug.  If you are finding it unreadable, please provide a screenshot of a nightly build so we can compare it with how it was before.
Hey Guys,

@:bgrins - This bug itself has 2 screenshot issues
1. Firebug theme (which is getting fixed...
2. A fixed 12px issue [1]

I've found the 80% Font size OK in Ubuntu 14.04+ and Fedora 22+
However the fixed font size is a concern, for Windows and Mac - the font size is inherited from "font: message-box;" which ensures high end DPI too it works.. but poor linux guys are left to strange quirks.

Again personally 80% size quirk helps, 11px size might not work for long (as higher DPI screens come into market)

Also isn't bug#900173 old, before the polished light and dark themes came? 

Im attaching a comparison of 11px vs 80% devtool screenshot.

[1] - https://twitter.com/fvsch/status/796365775749652480
This is from same openSUSE 42.1/KDE3 host 00srv and same profile used for attachment 8818172 [details]. It's clearly worse, than before this bug was "fixed" by attachment 8818052 [details] [diff] [review].
host gx780
Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0; Build ID: 20161215061212
I forgot to mention the extra Inspector window in comment 33's attachment 8819203 [details] is SeaMonkey rv49 20161005013219, the latest available GTK2 build of SM I could find.
(In reply to Felix Miata from comment #33)
> Created attachment 8819203 [details]
> screenshot of Inspector in rv53 on a non-Gnome 120 DPI Linux installation
> 
I'm curious, how does Google Chrome's devtools render over here ?!
Clearing my NI? since there's been some discussion already since it was requested, and I have not followed this bug closely.
Flags: needinfo?(pbrosset)
I am using I on Kde on Debian Sid so for ani test I am available, in any case this is my screen of Firefox Dev Edition and Nightly with the Firebug theme.
(In reply to Felix Miata from comment #33)
> Created attachment 8819203 [details]
> screenshot of Inspector in rv53 on a non-Gnome 120 DPI Linux installation
> 
> This is from same openSUSE 42.1/KDE3 host 00srv and same profile used for
> attachment 8818172 [details]. It's clearly worse, than before this bug was
> "fixed" by attachment 8818052 [details] [diff] [review].

The theme used in those screenshots is the Light theme, not the Firebug theme, which is the only theme affected by this bug. The CSS rules directly target(ed) the Firebug theme.
Hope there is a button to adjust font size in Inspector. Can't find any in 52.0b1.
(In reply to Dan Jacobson from comment #40)
> Hope there is a button to adjust font size in Inspector. Can't find any in
> 52.0b1.

Hi, Dan. You should be able to use Ctrl + Scroll to increase or decrease the font size.
(In reply to Kimberly Pennington [:kimberlythegeek] from comment #41)
> Hi, Dan. You should be able to use Ctrl + Scroll to increase or decrease the
> font size.
Yes that works for the window of the main site I am browsing, but not in the window titled Developer Tools, no matter
if fullsized or not, and no matter which (thin) scrollbar I do it on in that window.
I conclude that people who click Inspect Element will just have to live with the font size choices that are hardwired into the browser somewhere.
(In reply to Dan Jacobson from comment #42)
> Yes that works for the window of the main site I am browsing, but not in the
> window titled Developer Tools

Oops. For the dev tools, it should be Ctrl + or Ctrl - to increase or decrease.
Alas Ctrl + or Ctrl - were the first things I tried. But thanks anyway.
OK now with 52.0b3 indeed CTRL + makes the Developer Tools window's font get bigger.
But then the item I was inspecting disappears, and I see "No element selected." and it takes TWO hits of
CTRL - to get it back!
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: