777898 - Font rendering broken on elements with certain CSS rules

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, defect)

Description

[Lyndon]

Attachment: Test case

Font rendering is broken in Firefox for certain parts of a corporate intranet application that I am building, appearing as though cleartype is not being applied.

The bug is most noticeable on Windows XP (SP2), which is currently still in use throughout our corporation. It also occurs on Windows 7 (SP1), though much more subtly. (I tagged this bug report as Win7 just in case that gets it more attention).

The bug seems to depend on the use of position:fixed, and I have produced and attached a test case with which the bug can be demonstrated through toggling the position:fixed attribute on the #container div. Interestingly I have also noticed though that with position:fixed applied, toggling certain other attributes will make the bug appear/disappear, some examples of which are referenced in the comments within the test case's CSS code.

Note that Verdana was only used in the test case for simplicities sake.

Further details about my configurations:
 - Firefox version 14.0.1 was used on both machines.
 - ClearType is enabled on both machines.
 - For the Windows XP machine, Firefox's about:config graphics/font related attributes were all left as default (render mode -1, etc).
 - For the Windows 7 machine, again the about:config graphics/font related attributes were left on their default values, with the exception of the cleartype render mode, which was changed for the purpose of the test, since in it's default setting GDI-Classic mode is always used for Verdana (which was just picked for simplicity). Screenshots were taken with rendering modes 2 and 4, both with position:fixed applied, and removed. 

In addition to Firefox, I also tested it in Google Chrome (v20.0.1132.57 m), Opera (v12 on both machines I believe), IE8 (XP machine), and IE9 (Win7 machine). The bug did not seem to occur in any of these browsers (though I did not check ultra thoroughly with an image editor's colour picker).

Comment 1

[Lyndon]

Attachment: Screenshot - XPSP2 Fx14.0.1

Comment 2

[Lyndon]

Attachment: Screenshot - XPSP2 Google Chrome

Comment 3

[Lyndon]

Attachment: About:support - XPSP2

Comment 4

[Lyndon]

Attachment: Screenshot - W7 Fx14.0.1 - RenderMode4

Comment 5

[Lyndon]

Attachment: Screenshot - W7 Fx14.0.1 - RenderMode4 no-pos-fixed

Comment 6

[Lyndon]

Attachment: Screenshot - W7 Fx14.0.1 - RenderMode2

Comment 7

[Lyndon]

Attachment: Screenshot - W7 Fx14.0.1 - RenderMode2 no-pos-fixed

Comment 8

[Lyndon]

Attachment: About:support - W7

Comment 9

[Lyndon]

Attachment: Screenshot - Win7 Google Chrome

Comment 10

[Loic]

Where is the bug? In the rendering of the word "Cancel"?

Comment 11

[Lyndon]

(In reply to Loic from comment #10)
> Where is the bug? In the rendering of the word "Cancel"?

If you look really carefully, you'll notice that the bug actually occurs in all text within the second (position:fixed) box, however it is by far most noticeable with the black button's text. Check the XPSP2 Firefox screenshot for the best example by far - compare the text of the two black buttons within the screenshot.

Comment 12

[Lyndon]

Quick update - I've just tested the following versions on the win7 machine, and it exists in all of them:

Beta: 15 (beta 2)
Aurora: 16.0a2 (2012-07-27)
Nightly: 17.0a1 (2012-07-27)

Comment 13

[Loic]

Okay, I see the issue with your snapshot on Win XP, words in the 2nd box are less "bold" than these ones in the 1st box.

And in about:config, which variable did you change? gfx.font_rendering.cleartype_params.rendering_mode?
If yes, which values did you choose?

Comment 14

[Lyndon]

On XP I changed nothing in about:config, rendering_mode is -1 (default).

On Win7 I changed the setting you just mentioned to test modes 2 & 4 - Win7 screenshot titles postfixed with "RenderMode2" and "RenderMode4" respectfully.

Comment 15

[Loic]

I tried on Win 7, gfx.font_rendering.cleartype_params.rendering_mode = -1 but I don't know if I see a difference. :|
http://i.imgur.com/o3jfs.png

Do you know the best values to reproduce it on Win 7?

Comment 16

[Lyndon]

(In reply to Loic from comment #15)
> I tried on Win 7, gfx.font_rendering.cleartype_params.rendering_mode = -1
> but I don't know if I see a difference. :|
> http://i.imgur.com/o3jfs.png
> 
> Do you know the best values to reproduce it on Win 7?

It is more difficult to see in Win7. Instead of trying to see the difference between the text in the two boxes in one screenshot, flick back and forth between the pair of screenshots with and without position:fixed, and you'll be able to see a difference!

It's a little easier to see on Win7 with gfx.font_rendering.cleartype_params.rendering_mode = 4. With mode 2, it's difficult to see the difference flicking between the screenshots when viewing them in the browser, but flicking between them in paint.net works. Ultimately you can always use the colour picker tool in an image editor like paint.net to confirm it.

Note, you might already know this, but using the Verdana font in the test case, the default settings of "gfx.font_rendering.cleartype_params.force_gdi_classic_for_families" and "gfx.font_rendering.cleartype_params.force_gdi_classic_max_size" mean that "gfx.font_rendering.cleartype_params.rendering_mode" = -1 is the same as "gfx.font_rendering.cleartype_params.rendering_mode" = 2.

Comment 17

[Loic]

Yes, it's better with gfx.font_rendering.cleartype_params.rendering_mode = 4 on Win 7:
http://i.imgur.com/LtWoW.png

Comment 18

[Lyndon]

I've just noticed that there are also issues with the font rendering of the browser interface itself in my Win7 screenshots; The firefox button is rendered with DirectWrite in all four, when it should be just two, and the tab text and url-bar text is rendered in DirectWrite in three of them, with one (mode-2 no-fixed) using GDI...

I just took some new screenshots again in my default v14.0.1 profile, and also in a fresh profile, and had the same issue, only in various different combinations...

I then tried Firefox 15beta2, and while the original issue I'm reporting here **still remains**, this odd interface bug does not occur. I'll attach those screens in a moment.

There does though appear to be an issue with the characters 'r' and 't' in  'Firefox'/'Aurora'/'Nightly' in menu button of the beta/aurora/nightly builds, when using mode 2. These characters are too far to the right. (I know that belongs in a separate bug report, only mentioning because it's related).

Comment 19

[Lyndon]

Attachment: Screenshot - W7 Fx15b2 - RenderMode4

Comment 20

[Lyndon]

Attachment: Screenshot - W7 Fx15b2 - RenderMode4 no-pos-fixed

Comment 21

[Lyndon]

Attachment: Screenshot - W7 Fx15b2 - RenderMode2

Comment 22

[Lyndon]

Attachment: Screenshot - W7 Fx15b2 - RenderMode2 no-pos-fixed

Comment 24

[kinokijuf]

Note: D2D must be disabled or not available for this bug to trigger.

Comment 25

[kinokijuf]

Can’t reproduce currently on FF 28.0.0 on Windows 8.1. Might as well have been fixed.

Comment 26

[Loic]

Reporter, are you able to reproduce it with the current release of Firefox?

Comment 27

[Lyndon]

Right, so this was a pain to reproduce, but I got there and it does indeed seem to have been fixed somewhere between Firefox 14 and 28.

Since I no longer have a copy of XP or an installation of 7 available, I had to try to create a new VM environment to reproduce the problem. I went through a hell of a lot of effort installing the OS and patches. It didn't show up on RTM, so I installed SP1, then all patches in Windows update dated prior to submitting the report, then IE8 -> IE9, then I went through every damn security bulletin from feb 2011 to jul 2012 manually downloading and installing every damn patch and couldn't reproduce it at any point. In the end it turns out that it only shows up if gfx.font_rendering.directwrite.enabled is set to true, which I'd failed to mention in the report and since forgotten I'd changed at the time. Damn it!

Anyway, with directwrite enabled and rendering mode set to 4 (requires restarting firefox to take effect btw), it shows in 14.0.1 as originally experienced when I submitted the report and it does not show in Firefox 28. I also tested on Firefox 29 on my Windows 8.1u1 x64 host and again it seems to be fixed. I checked screenshots in an image editor to be certain and the pixel colours are consistent.

I notice that kinokijuf above mentions that D2D must be enabled to see the bug, this does not appear to be true, only directwrite. In testing in the VM, D2D was not disabled and not forced, but troubleshooting info states in the VM that D2D is blocked due to driver issues (I hadn't installed a driver in the VM).

This can be closed now I think.

Comment 28

[Lyndon]

Oops, didn;t realise comments submit with saving a change to info at the top of the page, I'd rewritten in notepad to submit after, but never mind...

Further testing involving updating version 14.0.1 to newer versions (20.0.1; 25; 27.0.1; 28) shows that the bug was fixed specifically in 28.

Comment 29

[kinokijuf]

@lrebrown i said the exact opposite — that D2D must be DISABLED (it is enabled by default)

Comment 30

[Lyndon]

@kinokijuf, oh yes you're right, sorry, I don't know why I misread that. Regardless, fixed in 28 :)