Wrong browser.display.screen_resolution default causes inconsistent GUI appearance



14 years ago
11 years ago


(Reporter: ats-mozilla, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: CLOSEME 07/01, )



14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050909 Firefox/1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050909 Firefox/1.4

The browser.display.screen_resolution preference lets you set the display DPI
that Firefox will use. The default value, rather than being taken from the OS,
is forced to 96 DPI, which causes problems if you're using a display with a
different resolution. Mine's 72 DPI, so Firefox has much larger fonts than any
other GTK app I use unless I change the preference to match.

The problem isn't so much that the fonts used when rendering web pages are
large; it's the fonts in the UI (i.e. menus, toolbars, dialogs and so on).

I'd prefer it if Firefox tracked the system DPI by default -- if it's set
wrongly, then the user should fix it, not rely on applications to provide
workarounds. If that's not possible, then Firefox should at least use the system
DPI for GUI elements in order to match the appearance of other applications.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox with a new profile on a 72 DPI display.
2. Compare the font sizes in the GUI to any other GTK application.

Actual Results:  
The Firefox font size will be larger than other applications.

Expected Results:  
The Firefox font size should be identical to other applications.

This occurs both with the provided Firefox binaries and with my own build from
the 1.5b1 source.

Comment 1

14 years ago
Possibly related to bug 69205.
There is bug 114270 for windows, couldn't find a linux equivalent though.
I agree it should go back to using the system DPI by default on Linux. On my
case (132 DPI), the UI fonts were very small until I set it to use the system
DPI. On Linux, almost all applications follow the system DPI.
Yeah, this was done by bug 274712 and should not have been done, and certainly not without the approval of Gecko module owners.  It breaks the ability of point sizes to be used to adapt to higher resolution displays.

It's not related to those other bugs, except that the fact that the pref only works on Unixes, maybe Mac, OS/2, and BeOS might have led Ben to do this while working on Windows (where it doesn't work).
Ever confirmed: true
Flags: blocking1.9a1?
Flags: blocking1.8.0.2?
Flags: blocking-firefox2?
Actually, never mind.  I'm filing another bug for the problem I'm seeing; comment 0 sounds like bug 197037 which was fixed long before this bug was filed.
Flags: blocking1.9a1?
Flags: blocking1.8.0.2?
Flags: blocking-firefox2?
This bug is interesting, though.  What distros and desktop environments are you guys using?
Component: Preferences → GFX: Gtk
Product: Firefox → Core
QA Contact: preferences → gtk
Version: unspecified → Trunk
I'm using Debian stable with KDE (but the relevant setting is on XFree86's configuration, and was set by hand).

Comment 8

12 years ago
Does this bug still occur in a recent trunk build?

I think this was fixed by bug 327406
Whiteboard: CLOSEME 07/01

Comment 9

12 years ago
Closed: 12 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.