User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20130320 Firefox/22.0 Build ID: 20130320044721 Steps to reproduce: Apply patch https://bugzilla.mozilla.org/show_bug.cgi?id=852522 Actual results: System fonts are 96 dpi even though devPixelsPerPx set to 1.0 and my OS dpi is 120. Expected results: System fonts should honor dpi

No. System fonts should honor the Windows dpi setting -if- you leave the devPixelsPerPx preference at its default of -1.0 (which means "handle this automatically"). If you explicitly set devPixelsPerPx to a positive value, you're telling Firefox to -override- the system dpi/resolution setting, and so you'll get smaller (or larger) fonts throughout the browser, depending whether you set devPixelsPerPx to a value that's smaller or larger than the Windows resolution scaling factor.

Setting the pref to a positive value defaults to a 96dpi for 'system' fonts? If so, why not also downscale the chrome too? That remains the same size. A +1.0 is now not a method to keep Fx looking the same as before the dpi patch? idk Jon but all of these dpi changes so far have not been one of the best things I've seen you guy's do.

(In reply to Gary [:streetwolf] from comment #2) > Setting the pref to a positive value defaults to a 96dpi for 'system' fonts? No, it uses whatever scale factor you specify. If you set it to 1.0, *then* yes, you're effectively asking for 96 dpi; if you set it to 1.25, you're asking for 120dpi-sized fonts; if you set it to 1.5, you're asking for 144dpi-sized fonts; etc. Until the recent changes, I think you were seeing system fonts sized according to your chosen Windows scale (i.e. 125%), but content that ignored the Windows setting (and so you were then "zooming" the content to make things readable). That's not a sustainable model, as resolutions continue to increase. We really HAVE to start honouring the Windows resolution setting in a consistent manner across the whole browser, that's the only reasonable way forward into a world of displays with widely varying DPI. The expectation is that there shouldn't normally be any need to change the devPixelsPerPx setting from its default of -1.0; that should give a correctly-scaled view (both the chrome and content) for your screen, consistent with other Windows applications. If you *do* start changing that preference, you are completely overriding the effective DPI setting for Firefox, and both chrome and content will scale accordingly.

So I should consider all of this a Work In Process and the final version will be a lot better visually then what I see at this point?

Well, we certainly want appropriately-sized graphic elements for the UI, so that we don't upscale smaller bitmaps. That's a known issue, as has already been stated. So yes, it's a WIP. In terms of scaling things in response to the system resolution setting, I think most stuff is now working as expected; if it's not, we certainly want bug reports. But this particular one was based (AFAICT) on a misunderstanding of the whole resolution-scaling model.

The chrome portion is something you guys can control. Content is another thing. Go over to www.weather.com. At 125% the page is Hugh. Is there anything you can do about something like this? I can still do text zoom and full page zoom with the built in zoom or NoSquint to reduce the size. The thing is that a person who writes an application taking in mind the OS dpi will provide all that is needed to handle them. Web pages for the most part do not take into account dpi, although you said they are able to. So each web page is like an application which you don't have full control over to make it look visually appealing. Is there any push my Mozilla or the other browser makers to spread the news to web designers to code for different dpi's? That's what is needed to get pages looking good.

Text-only scaling of web pages was abandoned several years ago by the w3c because it was notorious for breaking layouts. Proportionate scaling of everything (text, boxes, images) is the preferred way to scale web pages. (See -webkit-text-size-adjust for one noteworthy exception.) Many websites these days are serving images optimized for high DPI devices. eg: http://www.apple.com/ http://www.google.com/ http://mail.google.com/ http://www.microsoft.com/ Want me to attach images of these sites viewed at 192dpi? :D~

bug 712898 comment 28: "System metrics and native theme drawing are always in device pixels." System font sizes should be system font sizes. CSS pixel sizes are not involved.

In effect, you are asking to back out Bug 852522.

It will totally break the rendering on High DPI monitors.

(In reply to Greg Edwards from comment #9) > In effect, you are asking to back out Bug 852522. I don't know the pixelScale code, so perhaps that should remain. All I know is that devPixelsPerPx should not be involved.

(In reply to Masatoshi Kimura [:emk] from comment #10) > It will totally break the rendering on High DPI monitors. Do you mean backing out bug 852522 would break that or fixing this bug, or are they the same thing? Why would respecting system font sizes in this case be any different from respecting other changes in system font size settings?

What's the definition of "system font size"?

Karl: I'm pretty sure he means it will cause text to overflow outside of dialogs and widgets because the font size is too big for them. This is why bug 852522 was originally implemented--to make the sizes of containers match the sizes of fonts. (Before you say anything, making the containers grow to match the fonts is what the default, uncustomized devPixelsPerPx setting does.)

System font sizes describe the size of fonts as specified in the system themes. On WINNT, the fonts in menus, for example, come from the theme Menu font. The Message Box font is used in much of Firefox UI. I don't know where other fonts come from. The system UI for configuring the themes presents font sizes in points, so I assume the system fonts sizes in layout device pixels are something like point size / 72 * logical dpi. If LookAndFeel reports system metrics in device pixels, as it currently does, then, on platforms where system metrics depend on window scaling, the functions reporting the metrics need to know the window scale. On platforms where the window scale is the same for all windows, the system metrics functions don't need to know the particular window and can just use the global scale. Currently these functions are passed the device pixels per CSS pixel ratio which defaults to the window scale, but is not the window scale if the pref has been set. Really the pref should affect the rendering of CSS pixels, but system metrics are unrelated to CSS pixels. On WINNT, fixing this bug involves simply backing out bug 852522. On platforms with different window scales for each window, it is harder. The pref in its current form is not so useful on systems with different scaling on different windows. Perhaps the pref has changed in meaning from allowing the user to specify CSS pixel size to allowing developers to experiment with overriding system window scaling. But the name of the pref implies that it affects CSS pixels.