Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 433664 - font size does not increase with DPI setting
: font size does not increase with DPI setting
Status: NEW
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: x86 Windows XP
: -- major with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 420950 (view as bug list)
Depends on: 426788
Blocks: 469306 378927
  Show dependency treegraph
Reported: 2008-05-14 00:44 PDT by Csimbi
Modified: 2011-06-23 02:56 PDT (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

144 DPI WinXP screenshot (181.84 KB, image/jpeg)
2011-05-05 22:26 PDT, Felix Miata
no flags Details
144 DPI Linux screenshot (198.13 KB, image/png)
2011-05-06 03:51 PDT, Felix Miata
no flags Details
UA vs Physical: 96dpi Debian (58.67 KB, image/png)
2011-06-23 02:54 PDT, Ahmad Syukri
no flags Details
UA vs Physical: 168dpi Debian (81.90 KB, image/png)
2011-06-23 02:55 PDT, Ahmad Syukri
no flags Details
UA vs Physical: 168dpi Debian with 1.75 devPixelsPerPx (118.84 KB, image/png)
2011-06-23 02:56 PDT, Ahmad Syukri
no flags Details

Description Csimbi 2008-05-14 00:44:46 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080404 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080404 Firefox/

I became a happy owner of a 24" display recently.
I had to change the DPI setting because in 1920*1600 everything became nearly unreadable (I don't have so good eyes anymore). The new DPI setting is 144 (150%).
My homepage is set to Google - however it seems that it does not matter which page I am looking at.
Anyway, after I changed the DPI and restarted my PC, I checked IE6 first. IE6 scales up the fonts properly without any additional messing around, so I expected Firefox to do the same thing, however Firefox does not do anything: same tiny fonts (manual adjustment on every page does not count). I was able to find extensions that imitate the IE-like behavior - to scale all pages automatically, however I was not satisfied with the results. It would be nice if there was an internal scaler that could be replaced by extensions if needed.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox and take a look at a web page; take mental note (screenshot) how it looks.
2. Buy and add large flat panel (24" or bigger)
3. Change DPI to 144.
4. Start Firefox and take a look at the same web page and compare with its earlier look.
5. Realize that Firefox did not do anything, and the font size is tiny (nigh unreadable).
Actual Results:  
Font size remains the same in 96 and 144 DPI.

Expected Results:  
Font size to be scaled up according to the DPI setting on every page.

There are some extensions that do this on a per page basis (or, for all pages), however they are not good enough. Besides, I think that this should be a base functionality in Firefox, so one should not hunt for and experiment with a bunch of useless extensions.

I marked it as a major problem for now for these reasons:
 - there is no good workaround (the again, the available extensions less than satisfactory)
 - the small font tire my eyes very quickly (not ergonomic)
 - IE6 provides this already and Firefox is still lacking this? Come on!
Comment 1 Nochum Sossonko [:Natch] 2008-05-14 16:10:13 PDT
In firefox 2 you can easily scale fonts by going to View-->Text Size-->Increase, or better yet you can change the default font size in Tools-->Options-->Content.

Firefox 3 (coming out soon) has a feature to scale full web pages at a shot!!

(alternatively you can just press ctrl-shift-+ key combination and not have to go through the menus)!

I hope this helps you, although I still think the DPI setting should have an effect on Firefox.
Comment 2 Csimbi 2008-05-21 17:40:50 PDT
Hi Natch,
thanks for the reply.
Yes, I am aware of these workarounds, the shortcuts, etc.
The view->text thing does not stick (setting is dropped), and does not scale the text properly, neither (there are some portions of text that remain unscaled).
The tools->options variant does not work as expected: some fonts are changed (the font, not the size) while some are left the same font and size.
So, I would like to leave it open for now and hope it will be backported from FF3. But, I am a little sceptic about FF3 scaling, let's see when it's out.
Comment 3 Nochum Sossonko [:Natch] 2008-05-21 17:54:50 PDT
If this changed since the new firefox 3 (i.e. firefox 2 handled it fine) AND this problem is still there on the latest nightly, then I'd suggest you set this bug as blocking bug #378927.

Please try it though on the latest nightly first to see if the latest code still has the problem.
Comment 4 Philipp Wolfer 2008-10-21 17:01:18 PDT
I've got this problem with the 3.0.3 release in Ubuntu Hardy. The default font size is ridiculous small if a page uses relative font sizes, often nearly unreadable.

I tried to increase layout.css.dpi which shows no effect up to 191 DPI. At 192 DPI the font sizes suddenly change to be really large, in addition the toolbar icons also increase in size. Increasing the DPI setting even more seems to have no effect again.

My current workaround is to set the minimum font size to 12pt, but this breaks many layouts. Zooming the page is not an option since it will zoom everything on a web page, including the graphics (nice feature, but not the correct solution for this issue).
Comment 5 Michal 'hramrach' Suchanek 2008-10-29 07:06:18 PDT
It looks like Firefox does not recognize the DPI unless set in about:config

(look for the dpi setting there)

Also firefox seems to set default font size in pixels because the font size does not change even if the DPI is changed, it has to be set manually to a dpi based size in a css.

Firefox 2.0.14 on NetBSD (linux emulation)
Comment 6 Nochum Sossonko [:Natch] 2008-11-25 10:43:04 PST
*** Bug 420950 has been marked as a duplicate of this bug. ***
Comment 7 Jo Hermans 2009-01-05 04:23:17 PST
will probably be solved in bug 426788
Comment 8 Felix Miata 2009-01-11 03:50:29 PST
This should be a core bug duplicate of bug 186718 but 186718 is marked SeaMonkey rather than core.
Comment 9 Nochum Sossonko [:Natch] 2009-01-20 10:24:11 PST
Confirming. If bug 186718 is indeed a Core bug, please mark it as such and dupe.
Comment 10 Felix Miata 2009-01-20 10:55:31 PST
If this is a core bug, then bug 186718 is no less a core bug, which would make this the dupe of a core bug reported over 6 years ago.
Comment 11 Nochum Sossonko [:Natch] 2009-01-20 11:11:43 PST
The truth be said, this really belongs in Firefox, if I read bug 186718 correctly. This is because of certain settings (using px instead of pt) which I imagine are specific to each app. Then again, like I said, feel free to dupe if I'm wrong.
Comment 12 Felix Miata 2009-01-20 11:41:34 PST
I don't think this reporter's complaint has anything to do with specific sizes for the selected fonts for either app, but rather the fact that the sizes are listed in px rather than pt. Most apps size text in pt. If Gecko sizes were set in pt, then the selected sizes would grow or shrink as DPI varies (away from 96), as this bug's summary indicates, whether in Firefox or SeaMonkey. As long as they remain indicated in px, raising DPI will not increase the sizes, which makes Firefox defaults smaller than IE defaults as long as the user does not make a manual adjustment to compensate for a DPI increase.

A switch to pt however would increase the granularity of selections available. At 144 DPI for instance, the pt to px ratio is 1:2, which would cut the selections in about half from the 75 DPI of many older and Linux displays, and by about 1/3 from the 96 DPI usually assumed by Windows, OS X, and many recent Linux distros.

Note too the other bug is marked cross-platform, which this should be, as it affects Linux too.
Comment 13 Ria Klaassen (not reading all bugmail) 2009-02-06 14:23:04 PST
I have a similar problem with a WUXGA laptop and the extension Glazoom ( ) helps a bit by setting one fixed size for all pages (I'm using 133% currently). Plus you find (just like IE8) a little expandable menu on the statusbar. 133% is still a bit too small and 150% is way too big, there is nothing in between, that's why it will never be a comfortable computer (but great for photographs).
Comment 14 WulfTheSaxon [:Wulf] 2009-02-06 14:57:42 PST
I've filed bug 477213 for supporting the layout.css.dpi pref on Windows. I'm guessing it should either block or depend on this bug.

For the folks who are saying that the fix is to stop specifying the font size in px: The definition of a the "px" unit in CSS 2.1 is not the same as a physical pixel. It is to be scaled according the the user's DPI. See
Comment 15 Felix Miata 2009-02-07 11:01:42 PST
Same with SeaMonkey
Comment 16 Gili 2009-04-22 19:45:55 PDT
FireFox is at least somewhat usable under high DPI under Windows. Thunderbird is not. HTML messages are rendered using 4-pt font (?!?). It's completely unreadable at 1280x1024 monitors.
Comment 17 costinel 2009-11-25 05:11:25 PST
this is still an issue on windows xp with 144 dpi. firefox 3.5 worked just
great. i upgraded to 3.6.b3 and suddenly the gui collapsed. screenshots with
3.5 and 3.6b3: (3.6b3) TOO SMALL (3.5) SLIGHTLY TOO LARGE, BUT IT'S MUCH
MORE CONFORTABLE TO THE EYE, working 8 hours a day at 37' from 2 meters

if i managed to workaround websites with defaultzoom level extensio, the gui is a terrible mess in 3.6.b3!
Comment 18 Sylvain Pasche 2009-11-25 05:48:30 PST
The behavior changed intentionally, see bug 426788.

If you want the same behavior as Firefox 3.5 when using 144 dpi, go to about:config and set layout.css.devPixelsPerPx to "2".

If you want a behavior that kind of matches other Windows applications (and IE) when using 144 dpi, set layout.css.devPixelsPerPx to "1.5" (1.5 = 144 / 96).
Comment 19 costinel 2009-11-25 12:02:24 PST
oh, thank you Sylvain, your hint saved my day (actually, evening!).
I played a little with ranges from 1,4 to 2 and found that 1,7 is the perfect value for my eyes. Also had to figure that I must enter comma and not dot, since my locale has comma for decimal separator.

Comment 20 Tim (fmdeveloper) 2009-12-07 21:39:42 PST
*** Bug 531299 has been marked as a duplicate of this bug. ***
Comment 21 Marcus Groeber 2010-01-31 14:16:22 PST
(In reply to comment #18)

> If you want a behavior that kind of matches other Windows applications (and IE)
> when using 144 dpi, set layout.css.devPixelsPerPx to "1.5" (1.5 = 144 / 96).

Thanks - I was affected by this issue after upgrading from FF 3.5 to 3.6 as well, and I guess many other users of 1920x1080 displays as well. My personal preference would be for the behaviour in 3.5 (which indeed stretched the UI a bit much, but at least produced web sites scaled in line with the DPI setting by default, and with the expectation set by other Windows apps).

A small note on this workaround: depending on the decimal separator in your locale, this value has to be typed as "1,5" rather than "1.5" (e.g. German), or it will be ignored.
Comment 22 Martin Jürgens 2010-02-14 13:23:24 PST
this is a bad default behavior, as most people probably want firefox to also display text bigger than before with a lower dpi setting
Comment 23 Felix Miata 2011-05-05 12:55:18 PDT
Maybe Gecko should watch for DPI changes and when one occurs pop up a dialog asking the user to choose among:

1-have Gecko inherit its font defaults from the DTE rather than using its own
2-have scaling the way IE does turned on (by adjusting layout.css.devPixelsPerpx), allowing fine tuning via the prefs panel
3-open the font prefs panel along with a help window or pane suggesting what the individual prefs be changed to based upon the amount of DPI change
4-doing nothing

For Vista & W7, maybe it's time to incorporate suggestions from
Comment 24 Danial Horton 2011-05-05 13:02:15 PDT
isn't it layout.css? that seems to work just fine.
Comment 25 Danial Horton 2011-05-05 13:02:49 PDT
err layout.css.dpi infact.
Comment 26 Felix Miata 2011-05-05 22:26:21 PDT
Created attachment 530543 [details]
144 DPI WinXP screenshot

(In reply to comment #24)
> isn't it layout.css.dpi? that seems to work just fine.

It doesn't seem so fine here on a 144 DPI WinXP desktop. All 3 browsers are set to layout.css.dpi @ 0 and layout.css.devPixelsPerPx left alone in the 2 supporting it @ 1.0 default . Booted @120 DPI, all 3 do match.
Comment 27 Danial Horton 2011-05-05 23:18:10 PDT
thats because you set 0, if you set it to 96 it uses the same method as IE which is basically a default 125% zoom matching the dpi %
Comment 28 Danial Horton 2011-05-05 23:21:02 PDT
IE matches the 150% zoom to 150% dpi as well.

i prefer setting 96 and zooming since some VB forums have weird font sizing otherwise.
Comment 29 Danial Horton 2011-05-05 23:22:40 PDT

it seems this just got marked invalid, both have the same cause iirc.
Comment 30 Felix Miata 2011-05-06 03:51:49 PDT
Created attachment 530593 [details]
144 DPI Linux screenshot

Identical to attachment 530543 [details] except for taken on Linux instead of WinXP. This is the expected behavior, which is unavailable on WinXP.
Comment 31 Ahmad Syukri 2011-06-23 02:54:34 PDT
Created attachment 541322 [details]
UA vs Physical: 96dpi Debian

Screenshots of 3 different test cases of UA dimension vs physical dimension on Debian/Linux. First one is 96 dpi. Second is 168 dpi, which is my native resolution. While the last one is 168 dpi with layout.css.devPixelsPerPx = 1.75 (168/96).

All I can opine is that the root of all evil is the CSS 2.1 recommendation on length. Reference pixel is always from 96 dpi resolution. Therefore a 12pt text on a (Gecko) webpage will not be the same as 12pt text on other GUI widgets unless the resolution was 96 dpi.

Really, what is up with that spec? Display device is getting more modern, we will have very high density display (like iPhone 4's display) coming along. 96 dpi isn't going to make sense on those. It is time we treat 1mm or 1in as what they are. Maybe Gecko developers ought to propose to W3C for review on this particular section.

layout.css.devPixelsPerPx is not the solution because you'll lose pixel precision. Images get scaled up instead of being representated in the original resolution.
Comment 32 Ahmad Syukri 2011-06-23 02:55:50 PDT
Created attachment 541323 [details]
UA vs Physical: 168dpi Debian
Comment 33 Ahmad Syukri 2011-06-23 02:56:43 PDT
Created attachment 541324 [details]
UA vs Physical: 168dpi Debian with 1.75 devPixelsPerPx

Note You need to log in before you can comment on or make changes to this bug.