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.
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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).
Does this bug still occur in a recent trunk build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ I think this was fixed by bug 327406
Whiteboard: CLOSEME 07/01
Status: NEW → RESOLVED
Last Resolved: 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.