Closed Bug 1422598 Opened 7 years ago Closed 7 years ago

Firefox Developer Edition monospace font size doens't get applied.

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cvetan.simsic, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(8 files)

Selection_008.png
3.99 KB, image/png
Details
Selection_009.png
4.41 KB, image/png
Details
firefox-57.png
285.84 KB, image/png
Details
firefox-59.png
241.63 KB, image/png
Details
test.png
56.52 KB, image/png
Details
Screenshot-2018-1-30 Bug 1422598 Firefox Developer Edition monospace font size doens't get applied .png
73.66 KB, image/png
Details
static.png
141.93 KB, image/png
Details
dynamic.png
64.12 KB, image/png
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171129230835 Steps to reproduce: I frequently check some content in monospace font. For instance when i am working, anddo some lightweight debugging when i dump php variable in pre tags, var_dump or something similar. For that i always set monospace font size to 16 in preferences which is big enough for those situations. But no matter what size i set, it doesn't get applied. For instance the same settings in regular, stable Firefox work as they should. Actual results: Font size remains on default. Expected results: Font size should change accordingly.
Forgot to mention. Operating system is Ubuntu Linux 16.04.
cvetan, I think (although I am not 100% sure right now) you stumbled on a bug here. I can reproduce it with Firefox 52.5.0 ESR under Linux Debian (stretch) 9.2 with this test: http://www.gtalbot.org/BugzillaSection/Bug1422598-monospace-font-size-applying.html On your Ubuntu system, can you report what your system returns for: $ fc-match Courier $ fc-match "Courier New" $ fc-match "Lucida Console" I get "Nimbus Mono L", "Liberation Mono" and "DejaVu Sans Mono" which are 3 monospace fonts. If the font-family declaration is font-family: monospace then I get expected results. If a font substitution occurs in the list of font names, then font size for monospace in the user preference is not applied... which may or may not be a bug.
I get identical results with Firefox 52.5.0 ESR and Firefox nightly 59.0a1 buildID=20171203220339 .
I am enclined to think this is a bug but I am not sure right now. This bug report requires further triage and probably more testing. Like how div#test9 {font-family: inexistent, monospace;} is rendered in Windows 10, Mac OS X, Ubuntu 16.04 and Debian 9. We also need to verify how the test is rendered in other operating systems.
Component: Untriaged → Layout: Text
Keywords: testcase
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → All
Version: 58 Branch → Trunk
For the fonts on my system: fc-match Courier -> n022003l.pfb: "Nimbus Mono L" "Regular" fc-match "Courier New" -> Courier_New.ttf: "Courier New" "Regular" fc-match "Lucida Console" -> DejaVuSans.ttf: "DejaVu Sans" "Book" As for other things, i think this is bug guys. I use developer edition since it was introduced. I use it all the time for my development purposes, always have the same preferences and it worked as i mentioned until some time ago. I think with quantum it became like this. Although i can't explain why it doesn't happen in Firefox 57, stable.
Cvetan, I differ with regards to "Courier New": the font substitution on my Debian os is LiberationMono-Regular.ttf: "Liberation Mono" "Regular". Regarding div#test4, I also get: fc-match "Lucida Console" -> DejaVuSans.ttf: "DejaVu Sans" "Book" but the used font name by Firefox is "DejaVu Sans Mono", which is, in my Firefox setting, my selected font for monospace. DejaVuSans.ttf is not DejaVuSansMono.ttf.
I believe the Monospace font-size setting in about:preferences#content / Advanced... is associated with the CSS generic family name monospace; it is not expected to apply to "any font that happens to be monospaced". What does surprise me, offhand, is that it seems to be used only when the font-family property is exactly the single keyword 'monospace'; I was expecting it would apply any time the first family in the list was 'monospace', but this doesn't appear to be the case. Even the (otherwise redundant) "font-family: monospace, monospace" is enough to defeat it. So this seems like a possible bug in how the computed value of font-size behaves.
Component: Layout: Text → CSS Parsing and Computation
I have added div#test5 {font-family: inexistent, monospace;} div#test6 {font-family: monospace, monospace;} to http://www.gtalbot.org/BugzillaSection/Bug1422598-monospace-font-size-applying.html
There's code in nsRuleNode (IIRC) that checks specifically for the case where the font-family list contains a single entry which is a CSS generic, and I think that's the only case where the monospace-specific font size pref comes into effect. Whether that's the correct design is another matter; offhand it does seem a bit odd. Intuitively, I'd have guessed the pref would be used based on the first family name in the list, not whether it's the sole entry.
Something is definitely wrong here. You will see two image links. First is correct fonts in regular Firefox. Second is corrupted fonts in Developer edition. https://postimg.org/image/kfncn8l3v/ https://postimg.org/image/erh1wee7f/
I reversed order of the images by error. First one is corrupted Developer edition, second one is regular Firefox.
BTW here is this test link example. https://postimg.org/image/uqzpfrurv/
If you have screenshots to show, please don't post links to an image-hosting site, where they get surrounded by distracting ads etc. Instead, just attach your screenshots directly to the bug report using the Attach File link (above the comments, just below the Details section).
Yes. Cvetan, please don't use an image-hosting site. Also, it is preferable to always identify browser version with its buildID (it's the 3rd line in about:support). In 1 month (or 2 years), "regular Firefox" and "Developer edition" will not be explicit and clear while Firefox/57.0 Build ID: 20171129230835 will always be.
How is this still unconfirmed? I posted screenshot from the test mentioned above. I am sorry for the linking to image posting site. I thought all the latest info should be posted through comment. And there is no option to upload in comment.
> How is this still unconfirmed? I believe there is a bug here but, as of right now, I am still not sure what exactly it should be. Linux does font substitution for each font name that is not installed on the operating system eg $ fc-match inexistent DejaVuSans.ttf: "DejaVu Sans" "Book" Other operating systems do not do that. Under other operating systems, the browser looks at the next provided font name in the font-family list. Today I read and tried understand what fontconfig file do. I am not an expert of fontconfig file. > We also need to verify how the test is rendered in other operating systems. Another thing is that other browsers do not allow users to set a specific font size for monospace (fixed width). Chrome and Chromium do not allow that. IE11 does not allow that. Most likely Edge 15+ do not allow that. I don't know about Safari 11.x, Opera and Vivaldi. - - - - - - The way div#test5 {font-family: inexistent, monospace;} is rendered looks like a bug to me ... but maybe this should be filed under Linux Debian and not under Mozilla. The way div#test6 {font-family: monospace, monospace;} is rendered looks like a bug to me ... but maybe this one should be filed under Mozilla. I am not sure about the other 4 sub-tests because, it seems to me, the operating system is interfering with what CSS2.x, section 15.2 Font matching algorithm, is stating: " (...) If there is no matching font face within the 'font-family' being processed by step 2, and if there is a next alternative 'font-family' in the font set, then repeat step 2 with the next alternative 'font-family'. (...) " https://www.w3.org/TR/CSS21/fonts.html#algorithm https://www.w3.org/TR/CSS22/fonts.html#algorithm
> How is this still unconfirmed? We all understand your desire but, as an experienced bug reporting and CSS test person, I can assure you that you want to a) carefully read the spec or any normative specification, b) create judicious tests and c) carefully research issues involved. And I am not even a software developer here: so there are areas where I am "blind" or my opinions have no usefulness, no worthiness. Several years ago, I created a test involving <tt>, <code>, <kbd>, <samp> and how monospace fonts are handled. Here's a modified (according to this bug report) version of it: http://www.gtalbot.org/BugzillaSection/font-size-code-kbd-samp.html Now, if you load that test in IE11, the font-size of the monospace of the <span> will not be 13px but 16px. (This is what I found a few years ago with IE11: see next section) Not so, in Firefox. I wanted to file a bug over at microsoft but, for unknown reasons, I forgot or changed my mind or I was no longer sure or something else. - - - - - - - Another possible web ressource possibly relevant for this bug report: Fixing browsers’ broken monospace font handling http://code.stephenmorley.org/html-and-css/fixing-browsers-broken-monospace-font-handling/ (IE/O refers to Internet Explorer and Opera, GC/S refers to Google Chrome and Safari, and FF refers to Firefox) IE/O GC/S FF <pre> 13px 13px 13px <span style="font-family:monospace;"> 16px 13px 13px <div style="font-size:16px;"><code> 16px 16px 16px <div style="font-size:1em;"><code> 16px 13px 13px <div><code style="font-family:monospace,monospace;"> 13px 16px 16px <pre><span style="font-family:monospace,monospace;"> 13px 16px 13px (IE/O refers to Internet Explorer and Opera, GC/S refers to Google Chrome and Safari, and FF refers to Firefox) What is not known here is the browser versions involved and how the latest Edge 16 handle those tests. - - - - - - - I have added div#test7 { font-family: monospace, inexistent; } to http://www.gtalbot.org/BugzillaSection/Bug1422598-monospace-font-size-applying.html
CC Manish, which did a bunch of work in generic fonts in the style engine that landed in 57.
OK guys because i see this is still open for debate. Let me ask you in layman terms. Should changing font size in preferences change font in page? Regardless of operating system. Or is the font size preference exclusive to Windows systems? I am not trying to troll believe me, but i am suprissed that this is still not labeled as bug. I don't have to be experinced bug reporter, or CSS expert to know that my selected preferences don't work.
> Or is the font size preference exclusive to Windows systems? No. > Should changing font size in preferences change font in page? The logic behind where the font size prefs apply is a bit tricky. It's not that simple a question. The fact that it behaves differently in dev edition and stable makes me think it's a bug, however.
Cvetan, I am convinced that Test 5 The quick brown fox jumps over the lazy dog. Test 5 uses font-family: inexistent, monospace Test 7 The quick brown fox jumps over the lazy dog. Test 7 uses font-family: monospace, inexistent should be using the default monospace font with a 32px font size, if you set Fixed Width to 32 and set Minimal font size to None in http://www.gtalbot.org/BugzillaSection/Bug1422598-monospace-font-size-applying.html Those 2 subtests already exist in attachment 272334 [details]. There are other issues being tested and involved, happening here: - Windows and Mac OS X 10.x do not, as far as I know and understand this and how fontconfig under Linux works, make font substitution; Linux does. And that can cause your selected font size preference for Fixed width font in Firefox to be ignored - Browsers do not handle monospace font size the same way: we have tests and an article on that specific claim - Firefox allows users to customize text size of Fixed width font; IE11, Chrome (since version 1), Edge 16 (presumably) do not. I presume Opera (version 40+) and Vivaldi do. It is important to distinguish and untangle all as cleanly as possible.
I think it doesn't matter how Linux font substitution work if it worked until couple of versions ago. One think that is still unclear to me, is that when 57 version was in Developer edition the issues were present. Version 57 is now in stable Firefox there is no that issue.
Is there something specific in Developer edition related to issue at hand?
No matter what i choose in options for font same result. Nothing changes. I tried monospace, Dejavu Sans Mono, Monaco, Fira Code... Nothing.
Priority: -- → P1
This only gets worse. On the images i uploaded now, you can see some search form on the project we are currently working on. First image is Firefox 59, and font is not rendered properly. That is Font Awesome. Other is Firefox 57 and it shows correctly.
Attached image Selection_008.png —
Attached image Selection_009.png —
Priority: P1 → P3
How is priority getting lower? Issue is confirmed. Multiple times. Or you are pushing things under the carpet? Firefox is my browser since i started using Internet but, this bug and attitude around here about it is really pushing me away from it. I would certainly like to see reason behing lowering priority on the bug as big as this one. BTW this isn't only monospace font issue anymore, as you see font awesome isn't rendered. And fonts are messed up all around. I even argued with the our frontend developers, told them they messed up style, because i forgot to check up in regular Firefox. All OK there. Anyway, i will not report anything anymore beacause obviously there is no point.
(In reply to Jonathan Kew (:jfkthame) from comment #7) > I believe the Monospace font-size setting in about:preferences#content / > Advanced... is associated with the CSS generic family name monospace; it is > not expected to apply to "any font that happens to be monospaced". I am working on a new test based on your assumption. - - - - - - - My Debian 9.3 replaces Courier with "Nimbus Mono L" most likely because " (...) Nimbus Mono has metrics that are very similar to Courier (...) " https://en.wikipedia.org/wiki/Nimbus_Mono_L */ There is no font substitution by my Debian 9.3 and by Cvetan's Ubuntu 16.04 for "Lucida Console" (div#test4 in my previous test) in which case the generic monospace font should be fetched and loaded (it is indeed fetched and loaded in both Firefox 52.6 ESR and Firefox 60.0a1 buildID=20180125104809 on my system) along with the predefined font size setting as set in about:preferences#content (but it is *not* using the predefined font size for Fixed width). I am working on a new test that will try to demonstrate, highlight all this as cleanly as possible. - - - - - - - > Issue is confirmed. Multiple times. Please read comment 18 and comment 22. The way Firefox (versions 52.6 and 60) handle div#test2 and div#test3 should not be considered buggy due to font substitution by the Linux os. So font size might indeed change unexpectedly for those 2 subtests. And again, Firefox (all versions) allows users to set size of Fixed width: not so in IE11, not so in Chrome (all versions) and presumably not so in Edge (all versions).
How could not this considered buggy?! It worked as it should until couple versions ago. It was the same Linux system. Something was messed up badly in the recent versions no matter how you call it. It will not dissapear if you ignore it, but Firefox will loose more users in the process. I attached couple of more screenshots. And the issue is not only monospace fonts, but all the fonts. On the screenshots you will see Firefox 57, rendered good, beside the monospace fonts, because issue landed in 57. Other screenshot you will see Firefox 59. Search form not rendered (font awesome) and all the fonts are displayed differently. Last screenshot is test from the link above.
Attached image firefox-57.png —
Attached image firefox-59.png —
Attached image test.png —
You haven't provided the URL for the site shown in the comment 32 and comment 33 screenshots, so I can't verify this directly, but my guess is that this is a completely unrelated issue: the site is probably using webfonts that fail strict OpenType validation, which is applied in Nightly or Developer Edition builds, but not on the Release channel. If you set the option "gfx.downloadable_fonts.otl_validation" to false in about:config, you may find that many "broken" webfonts start to work again. If that's the case, those invalid font resources (more specific error messages will appear in the Web Console when validation is enabled) should be reported to the author/maintainer of the site.
This setting is already set to false. I can't share link because that is project in development. I thought screenshot will be enough to illustrate the point. What about the test results screenshot?
The screenshot looks like various webfonts are failing to load, but if it's not the otl_validation issue then I can't diagnose any further without having a testcase to reproduce the problem. Fonts in general seem to work OK for me, so I have to suspect there's something about your specific site that is important to the issue. So an actual testcase that reproduces the problem is really needed if we're going to investigate further. Or if you believe something has regressed recently, running the mozregression tool to identify exactly when it regressed would be very helpful. Your test.png screenshot is from attachment 272334 [details], right? AFAICS this is just exhibiting exactly what I described in comment 7 and comment 9: the preference for a default monospace font size is applied *only* if the font-family property specifies exactly the single CSS generic value monospace. It is not applied to other font names that happen to be fixed-width fonts; nor is it applied if the font-family property has a list of multiple names rather than just the single generic (as bug 175415 already describes).
OK. You can check here: https://shop.lilly.rs/srpski You will get different fonts in Firefox 57 and 59. For the monospace issue: How did this work as it should in Firefox 55, 54, 54, ... 40? Or you are telling me this is expected behaviour, and setting doesn't have any effect, and the last don't know how many years we used option that was not supposed to be there? I am not arguing just trying to make sense where there is any. Or at least not to me.
(In reply to cvetan.simsic from comment #38) > OK. You can check here: https://shop.lilly.rs/srpski > > You will get different fonts in Firefox 57 and 59. I get the same fonts in both 57 and 59 on that site. (Tried on Linux, Win10 and macOS.) In all cases, it's using a number of faces of Open Sans (from Google Fonts), plus FontAwesome (hosted locally on the site) for a few icons. Which suggests that there may be something unusual/different about your configuration or your connection or something. If you open the Developer Tools and force-reload the site, do you get any errors/warnings about fonts or about failed downloads or anything? If you look in the Element Inspector's Fonts panel, what font(s) does it report are actually being used in FF59 for the text that should be in Open Sans? Does your system have Open Sans installed locally (which would override the downloadable font)?
In Firefox 57 it says OpenSans. In Firefox 59 it is DejavuSans Bold.
Cvetan, You have not so far answered the important questions. Do you get any errors/warnings about fonts ... in Firefox 59? Does your system have Open Sans installed locally ... in Firefox 59? The fact that your site uses webfonts (web embedded fonts) makes my reduced tests *not* a reliable, trustworthy representation of your site problem. Regardless of how you anwer these, 1) bug 175415 is still a valid+confirmed bug report 2) the subtests 4, 5, 6 and 7 of http://www.gtalbot.org/BugzillaSection/Bug1422598-monospace-font-size-applying.html demonstrate real Firefox issues and 3) the article mentioned in comment 17 indicate real browser incompatibilities.
No i didn't have Open Sans font installed. I installed now in my system and that issues seems to be gone. But shouldn't that load web font and not my local font? CSS from Google? Why do my local fonts matter? As for the mentioned test, i don't think i understand you so i uploaded screenshot.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
It still doesn't work? How come it is resolved? One question if you view source of some webpage? Does monospace font settings should apply to that? View source? Because as earlier no matter what i set it remains the same.
(In reply to cvetan.simsic from comment #44) > It still doesn't work? How come it is resolved? I can not reproduce the problem you reported. If you create a *_reduced_* test [1] along with specific steps to reproduce, and if we can reproduce your findings, then we would be happy to confirm this bug and mark it as NEW. If the problem you see decisively depends on a webfont (Open Sans from Google Fonts, FontAwesome hosted locally), then the reduced test must be using it. Do you have a lot of add-ons installed in your Firefox 59 (or 60)? Do you still see the problem if you disable add-ons in Firefox 59 (or 60)? Help/Restart with add-ons disabled https://support.mozilla.org/en-US/kb/disable-or-remove-add-ons#w_how-to-disable-extensions-and-themes Can you reproduce the problem you see with in/with a new Firefox profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles#w_start-the-profile-manager-when-firefox-is-closed [1] How to Really, Really Help Developers on Bugs -- Minimal Testcases http://wiki.mozilla.org/QA/Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases - - - - - - > 2) the subtests 4, 5, 6 and 7 of > http://www.gtalbot.org/BugzillaSection/Bug1422598-monospace-font-size- > applying.html > demonstrate real Firefox issues and > the preference for a default monospace font size is applied *only* if the font-family property specifies exactly > the single CSS generic value monospace. Subtest 4 uses font-family: "Lucida Console", monospace . Linux substitutes "Lucida Console" for "DejaVu Sans Mono" without setting it to 32px. So, this substitution (without setting font size to 32px) may be unexpected but that's how font substitution process seem to be under Linux (Firefox's handling of subtest 4 under Linux is probably not a failure). In fact, this is what probably happens with subtests 2, 3, 4 and 5. For subtests 2 and 3, there is a predefined font substitution under Linux for Courier and "Courier New". - - - - - - Comment 39: do you get any errors/warnings about fonts or about failed downloads or anything? Comment 41: Do you get any errors/warnings about fonts ... in Firefox 59? No answer from you so far. Please report any errors or warnings (in CSS tab, Security tab, Network tab) from Web console (Tools/Web development/WebConsole)? - - - - - - > One question if you view source of some webpage? Does monospace font > settings should apply to that? View source? Monospace font settings does not have to apply to view source. There is no specification dictating that view source page should use monospace. But traditionally and historically, code - all sorts of programming code - resorts by default to monospace font. All other browsers (IE, Edge, Safari, Chromium etc) also use a monospace font to display view source. Firefox uses monospace font for view source because it is a de facto standard among browsers and for historical reasons.
I don't get any errors in the console. I don't have many addons installed. Only ublock and xdebug helper. Firefox 60. The funny thing is, it actually showed increased font size, like before Firefox 57, couple of times yesterday. But probably update came right after and then it reverted to behaviour i describe here. Since developer edition gets update all the time who knows what was it. :)
Little update. I noticed another weird thing. When i go to view source, of static html page, i get font size applied from settings. When i view source of another page on the web, or php page from localhost i got font size smaller that differ from settings. Check for the screenshots.
Attached image static.png —
Attached image dynamic.png —
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: