The default bug view has changed. See this FAQ.

Windows display resolution preference (DPI) is not reflected in UI for Mozilla's DPI preference (even though it's actually used instead)

REOPENED
Unassigned

Status

Core Graveyard
GFX: Win32
--
minor
REOPENED
16 years ago
6 years ago

People

(Reporter: James Crowson, Unassigned)

Tracking

Trunk
Future
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)
BuildID:    20011112009

In Windows you can set the system DPI to things other than the default 96, but 
Mozilla does not notice what you have set the system DPI to, and you have to 
input it manually.

Reproducible: Always
Steps to Reproduce:
1. Change the system DPI.  In Display Properties - Settings - Advanced - DPI 
setting (may be different if you don't have XP, but the feature's been 
available ever since Windows 3.1).
2. Reboot
3. Start Mozilla.

Actual Results:  Mozilla still thinks the display is 96 dpi.

Expected Results:  Mozilla should have read the system DPI via the 
GetDeviceCaps call and used that value for rendering.

The following code can be used to read the system DPI:

int intScreenXDPI, intScreenYDPI;
HDC hdcDesktop;
HWND hwndDesktop;

hwndDesktop = GetDesktopWindow();
hdcDesktop = GetDC(hwndDesktop);

intScreenXDPI = GetDeviceCaps(hdcDesktop,LOGPIXELSX);
intScreenYDPI = GetDeviceCaps(hdcDesktop,LOGPIXELSY);
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

16 years ago
Are you referring to the DPI dropdown in preferences->fonts?

This is not hooked at up at all on Windows.
(Reporter)

Comment 2

16 years ago
Well, you set it through that dropdown.  Shouldn't its default be the same as 
the current Windows system DPI?
Reassigning to Don.
Assignee: attinasi → dcone
Target Milestone: --- → Future
->GFX: Win32
Assignee: dcone → kmcclusk
Component: Layout → GFX: Win32
QA Contact: petersen → ian

Comment 5

14 years ago
*** Bug 161660 has been marked as a duplicate of this bug. ***
This behavior may be intentional -- by default, we shouldn't use a system DPI
that's less than 96dpi, but we should use it if larger, although the default
might be modifyable.

Comment 7

14 years ago
If Windows doesn't use the DPI stuff in prefs, it shouldn't be there.

The issue is that the user has the ability to change DPI in prefs, but it does
nothing.

Comment 8

13 years ago
*** Bug 247822 has been marked as a duplicate of this bug. ***

Comment 9

13 years ago
The screenshots in bug 247822 demonstrate that, at 144 DPI for Moz 1.7 at least,
Windows' system DPI is not ignored. If rather this bug is about the Moz DPI pref
being ignored in Windows, then the summary should be adjusted accordingly.
Otherwise, this is WFM.

Comment 10

13 years ago
Created attachment 152392 [details]
Test Default 12pt against Explicity 12pt

The dpi settings are ignored if the font size is not explicitly set in the
HTML.
With the attached test case, on a normal (96DPI) system, the font-sizes are the
same. But on a non-standard (eg. 120DPI) system, they're different!

Tested on firefox 0.9.1
Comment on attachment 152392 [details]
Test Default 12pt against Explicity 12pt

Our default font size is 16px, not 12pt.
Attachment #152392 - Attachment is obsolete: true
*** Bug 274848 has been marked as a duplicate of this bug. ***
*** Bug 274848 has been marked as a duplicate of this bug. ***
(In reply to comment #9)
> If rather this bug is about the Moz DPI pref
> being ignored in Windows, then the summary should be adjusted accordingly.

...and marked as a duplicate.

Comment 15

12 years ago
*** Bug 296501 has been marked as a duplicate of this bug. ***

Comment 16

12 years ago
*** Bug 291647 has been marked as a duplicate of this bug. ***

Comment 17

12 years ago
Can I suggest to increase the priority?
With the newest laptops with an high resolution display it is normal to set the windows DPI to 120 otherwise all the text will be really difficult to read.
The gmail website doesn't specify directly the font size and thus it is really broken in Firefox.

Comment 18

12 years ago
Conforming summary to comment 7. The Windows system DPI setting, 96 by normal default, 120 by default on many high resolution laptops, is not ignored. Either the pref needs to be made to work, or the pref panel needs to exclude display resolution.
Assignee: kmcclusk → win32
Summary: Windows system DPI is ignored → Windows display resolution preference (DPI) is ignored

Comment 19

12 years ago
Re Windows setting DPI to 120:  that's a deficit of Windows.

Measure your laptop, say 15" screen @ 1600x1200 -> 133.3 DPI. 
At 1920x1024, in a 15" frame -> / 145 DPI, 15.1 -> 144 DPI, 16" -> 136 DPI.

It's not just text -- it's also widget and picture sizing: things likely beyond the scope of this bug -- but too many webpages are designed for the mono-window, 1024x768 user (ex.: Tom's HW!).  

One can increase text size, but thanks to some stupidity somewhere, they still specify sizes in pixels.  HTML spec should get rid of idea of physical pixels & goto virtual pixels so entire displays in a given window can be resized on the fly.

Same problems with enlarging text does happen in FF as in IE though not as often -- I notice it more in IE as it respects the DPI and "Accessibility" restraints more so than FF, but conversely more websites are designed to use fixed pixel objects that get truncated or written over the top of things in IE with larger fonts.  Case in point is new CSS code in "/.".  Unless I set IE to display all text in "smallest", I have fields overwriting each other in IE.  Seems like they recoded to break compatibility with older browsers that default to allowing larger fonts.

Don't have micron level eyesite?  Too bad.

I can see why open source is getting bad reviews on accessibility issues.

Yes -- FF's "control-+" works when MSIE's "change font size" doesn't and has some benefits -- but the columns stay the same size -- if you make the text
large, you can end up with a few words/line in some badly designed websites, it's also a problem when your "control-+" setting doesn't follow you on other pages on the same website or in the same session.  Not sure what would add to least surprise, but it is a pain to open up several tabs from an expanded text webpage (control-+'d) then have to manually blow up text on each of them.

Perhaps this should be moved into the area of accessibility bugs?


Summary: Windows display resolution preference (DPI) is ignored → Windows display resolution preference (DPI) is ignored when less than 96
It's no longer clear what this bug is about.  I've adjusted the summary to what I think it was originally about.  I'm marking it wontfix since that behavior is intentional.

The other issue frequently mentioned here is bug 69205.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Hrm.  Actually, Windows is the only platform where we don't ignore the system's idea of DPI when it's less than 96dpi, so I'm really not sure what this bug is about, unless it's purely a duplicate of bug 69205.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Windows display resolution preference (DPI) is ignored when less than 96 → Windows display resolution preference (DPI) is ignored
Summary: Windows display resolution preference (DPI) is ignored → Windows display resolution preference (DPI) is not reflected in UI for Mozilla's DPI preference (even though it's actually used instead)

Comment 22

12 years ago
Based upon comment 0 alone this looks invalid, since the system DPI is in fact used. But, based upon the original summary and the comment 2 response to comment 1, it's apparently really about a UI pref that can apparently be changed, but without having any effect. Since comment 0 constitutes a dupe of bug 69205, but comments 1/2 constitute a valid separate complaint, we could simply resummarize this bug as a request to remove the UI pref panel item on this platform until and unless such time as bug 69205 gets fixed.

Comment 23

11 years ago
Is there a developers mailing list to discuss these issues?  This bug is only a small part of the problem(s):

The larger problem(s) are: 1) DPI settings are ignored (they should not be considered a "font-only" property)
2) User-setttings of Font size minimums appear to have no effect for a given language

Neither of the above problems should be considered 'minor'. Problem "1" is major and minimally should address placement and size of HTML widgets/structures (unfortunately, exluding graphical items), but ideally (eventually) including dynamic resizing of both static and dynamic graphical items.

There are several new bugs that also touch on font issues -- I was going to open another bug (or two) to address these larger issues, but don't really feel like just adding to the exsisting noise -- was hoping for a better venue to discuss these issues?
I wonder how cairoization is going to effect this... Pav?

Comment 25

11 years ago
I've suggested that we remove the UI for setting the "DPI" on various occasions.  If we want something similar, it should probably be more of a font scale setting than a DPI one.  We want to use the system DPI across the board for DPI-related matters.

Currently in cairo-land, we do mostly what we do now.. linux pays attention to that preference and windows completely ignores it.

I think we'll soon see a better solution all around, but i'm not sure what that is yet.
(In reply to comment #25)
> ...  If we want something similar, it should probably be more of a font
> scale setting than a DPI one. ...

Don't expect font settings in Firefox on Linux to affect every element on a page consistently:

On Linux, text font settings do not affect size of form controls (e.g. buttons, input fields, etc.) as their font sizes come from the system's fonts for form controls (-> GTK). In contrast to Windows where font settings do scale form elements. 

In bug 305109, I suggested that Firefox resolve this cross platform incoherency. Pity, it was rejected. This inconsistency is obviously intentional.

Comment 27

11 years ago
By 'linux does and windows doesn't', do you mean the 'linux' version of Tbird and Firefox _do_, pay attention, to the Display DPI, but the 'Windows' versions of Tbird and Firefox _don't_ pay attention to the Display DPI?  

Isn't it the case of this feature never being implemented in the mozilla/netscape Windows port?  

I seem to remember this problem in the earliest Window's ports of the product in the late 90's when run side-by-side on DPI-correct displays with Unix ports of the product.
-l

Comment 28

11 years ago
Comment 7 and comment 25 indicate that this bug should be about removing the DPI UI from the subject OS builds, so Linux discussion here is inappropriate.
I was referring to comment 25's suggestion to remove "the UI for setting DPI" in favour of a "font scale setting" and talking about what problems may arise. True, that was not directly belonging to this bug. 

Comment 30

11 years ago
Just ran into this one on Windows XP. Got a new 15" widescreen laptop with 1680x1050 resolution. I adjusted the Windows desktop to 106 dpi resolution (Windows allows resolutions other than 96 and 120!). 

IE picks up this resolution, and displays larger fonts, but FF continues to use 96 dpi (resulting in minuscule fonts). 

Worse, setting a custom DPI in FF preferences (what a weird GUI in 1.5 - making me measure a line - now where's my ruler?!) didn't help at all. I restarted FF, and apart from now displaying a blank in the resolution dropdown box, it had no effect on the displayed fonts.

FF should just pick up the Windows-reported desktop DPI values (doesn't *matter* if that is the "real" DPI - if IE uses it, and Office uses it, heck, FF should use it!) and automatically use that to scale the fonts for display.

I would like to bump this bug back to "normal" priority, as super high-resolution laptops and displays are becoming increasingly common, and FF looks really bad on these displays when the desktop is set to a comfortable font display size. And also maybe reset the Target milestone to something closer than "Future"?
After the fixes for bug 233082 and bug 323962, which are in Firefox 2.0 but not 1.5, Firefox will (again!) pick up the Windows preference.  This bug is about the user interface not reflecting reality, and/or not being able to change anything, not about the problem you mention (except perhaps for the ruler not doing anything).  (I haven't read it carefully enough to be sure which.)
Product: Core → Core Graveyard

Comment 32

6 years ago
IS ANYONE PLANNING ON FIXING THIS?

PROBLEMS:

1) I have Windows DPI set to 125%. Firefox sets my text and image DPI to 150%.

=== !!!!! 150% !!!!! ====
=== !!!!! 150% !!!!! ====
=== !!!!! 150% !!!!! ====

2) <CANVAS>, other elements WON'T GET RESIZED
A web-game that relies on <canvas> and other HTML GUI elements (like <img>) will make for a broken presentation, because <img> scales, while the <canvas> area will not.

3) Web developers can't change this, if they are working in PX! (you want images to be specified in ems?)

Chrome actually knows that I ONLY WANT MY WINDOWS GUI TO BE RESIZED and keeps everything normal.

SOLUTIONS:

1) Make Firefox reflect the ACTUAL Windows DPI. If I set 125%, then 125%.
2) Make a way for a NON-TECHNICAL user to modify the Firefox DPI. Many users don't want to change Firefox settings, but only the WINDOWS GUI settings.
3) Add a Firefox-specific CSS property that specifies to ignore the user's Firefox DPI settings.
You need to log in before you can comment on or make changes to this bug.