476250 - layout.css.dpi is not respected for system fonts but is respected for the user's font preferences

Status: RESOLVED WONTFIX

(Core :: Layout: Text and Fonts, defect)

Description

[Trustin Lee]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc10 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc10 Firefox/3.0.5

When layout.css.dpi is set explicitly (e.g. 96) and the actual DPI of a monitor is larger than that (e.g. 180), form controls does not seem to respect the 'layout.css.dpi' for form controls which did not specify 'font-size' style.

Reproducible: Always

Steps to Reproduce:
1. Click GNOME menu -> System -> Preferences -> Look and Feel -> Appearance -> Fonts tab -> Details... button, and set the Resolution to '180' dots per inch.
2. Launch Firefox and visit http://gleamynode.net/test.html
3. Three form control pairs (text input + submit button) appear.
Actual Results:  
The first two form control pairs look correct, but the last one looks awfully large.

Expected Results:  
the last form control pair should be seen as small as the first one (i.e. font-size: 1em)

Comment 1

[Trustin Lee]

Attachment: Screenshot: bugzilla.mozilla.org

Mozilla Bugzilla web site also has awfully large form controls with my configuration.

Comment 2

[Trustin Lee]

Attachment: Screenshot: gleamynode.net

My personal web site also has very large search form and 'donate' button.

Comment 3

[Trustin Lee]

Attachment: Screenshot: Test Page

Attaching the test page which demonstrates the problem with the three form control pairs.

Comment 4

[Trustin Lee]

I am able to reproduce this problem in 1.9.0 and 1.9.1 (i.e. Firefox 3.0.5 and Firefox 3.1 beta 2)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Is the issue still there if you use "-moz-appearance:none" on all the inputs involved?

Comment 6

[Trustin Lee]

Attachment: Screenshot: Test Page with Another Form Controls with '-moz-appearance: none'.

Yes, the issue is still there.  I updated my test page so that you can reproduce the problem.  I'm also attaching the new screenshot.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK, so the point is that inputs by default use a system font, and this system font's dimensions are given by the system in _device_ pixels, not CSS pixels.  So layout.css.dpi doesn't affect those dimensions, since it just affects the ratio of device to css pixels.

The user's font preferences, on the other hand, seem to be given in CSS pixels, as best as I can tell.  So we adjust the font sizes of non-system fonts based on the device-to-css pixel ratio.

The inconsistency does seem a little odd, but if anything the correct behavior should be to treat user font sizes as being in device pixels, no?  The current inconsistent behavior means that we scale up the UI _except_ for the text set to use system fonts when layout.css.dpi is set.  For example, the tab labels don't change size, though the size of everything 

Here's a simple example of the problem that doesn't involve form controls at all:

  data:text/html,<div style="font: -moz-field">Text</div><div>Text</div>

Just setting layout.css.dpi to 256 on a system which is actually closer to 100dpi makes the issue obvious here.

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

But changing the default font size away from 16px (CSS pixels) will break decent numbers of Web pages.

I think the current behavior is reasonable... if you *really* have a high DPI display, your system fonts are probably going to be bigger in device pixels than if you don't.  If you're faking it, you might get some strange results.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yeah, good point about having to size the default font size in CSS px.

I have no problem marking this bug invalid or wontfix; I just wasn't sure what exactly we want to be doing here.

Comment 10

[Trustin Lee]

(In reply to comment #8)
> But changing the default font size away from 16px (CSS pixels) will break
> decent numbers of Web pages.
> 
> I think the current behavior is reasonable... if you *really* have a high DPI
> display, your system fonts are probably going to be bigger in device pixels
> than if you don't.  If you're faking it, you might get some strange results.

My monitor's system DPI is set to 180 because I am somewhat visually impaired and I want all applications have larger texts.  However, I prefer to set layout.css.dpi because setting it to -1 or 0 breaks the look of many web sites.  Sticking to 96 DPI while zooming the page to 200% works around many layout issues of the existing sites.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Hmm.  Do you have examples of sits that break at the high dpi?  That's something that we should fix, if we can....

Comment 12

[Felix Miata]

Attachment: 144 DPI screenshot in KDE3 of a contextual testcase http://fm.no-ip.com/tmp/sc-b476250c0.html

I don't see a problem.

Comment 13

[Felix Miata]

Attachment: screenshot: 144DPI KDE & 168DPI Firefox

I think the reported "problem" is an extreme case. Most people will not use a browser DPI wildly different from the system DPI. IOW, nothing in Gecko is broken.

Comment 14

[Trustin Lee]

(In reply to comment #11)
> Hmm.  Do you have examples of sits that break at the high dpi?  That's
> something that we should fix, if we can....

Bugzilla.mozilla.org itself is a good example as the attachment shows.  Any web pages which did not explicitly specify the font-size of the form controls are affected by this problem.

The fact that most people are not affected by this issue doesn't mean that nothing is broken.  Also, I don't think this is an extreme case.  For example, Windows allows a user to specify very high DPI so that a user can see very large texts in applications.  So GNOME does.

In such a case (i.e. system DPI is very large), many sites will look broken unless layout.css.dpi is explicitly set to 96 (or something similar) instead of 0 or -1.

Comment 15

[Trustin Lee]

The sites that use pt or px will be fine, but those which use em or no style will look broken because it is calculated against the DPI value.  So, is I don't override layout.css.dpi to smaller value, text will look very large breaking the overall layout of the page.  That's why I set layout.css.dpi to 96, but the form controls are not affected by the new DPI while all other elements obey the new DPI.  Isn't it inconsistent?

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #14)
> (In reply to comment #11)
> > Hmm.  Do you have examples of sits that break at the high dpi?  That's
> > something that we should fix, if we can....
> 
> Bugzilla.mozilla.org itself is a good example as the attachment shows.

In that attachment you had set layout.css.dpi to 96, right? If you set it to -1, or what you told Gnome (180), does bugzilla look unacceptable?

We basically assume that system fonts are sized correctly as-is and that if you manually set layout.css.dpi, that you'll set it close to the system dpi, or you're just doing testing so you don't care if the system fonts look the wrong size.

I suppose we could figure out the ratio of layout.css.dpi to the actual system DPI, and scale the system font sizes by that ratio, but that seems like unnecessary work to handle a situation we don't really support.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I think I'm going to mark this wontfix on the basis of comment 8, comment 9, and comment 16.

(In reply to comment #16)
> I suppose we could figure out the ratio of layout.css.dpi to the actual system
> DPI, and scale the system font sizes by that ratio, but that seems like
> unnecessary work to handle a situation we don't really support.

But I think the main use case for layout.css.dpi is when our attempt to figure out the "actual system DPI" is wrong.  If that's the case, using the ratio of it to our incorrect guess doesn't seem like a good idea.