Closed Bug 69205 Opened 24 years ago Closed 14 years ago

pref browser.display.screen_resolution does nothing

Categories

(Core Graveyard :: GFX, defect, P1)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: kcha-ns-yka, Assigned: dbaron)

References

Details

Attachments

(3 files)

fix for the GTK port
650 bytes, patch
Details | Diff | Splinter Review
an attempt at a patch for the xlib port
6.09 KB, patch
Details | Diff | Splinter Review
1600x1200 resolution 144 DPI Win98 screenshot (24px default)
113.74 KB, image/png
Details
build 2001021420 and every other build I've used on win98SE The default value for pref browser.display.screen_resolution is 96 dpi. This is fine when using Windows Small Fonts, which is 96 dpi. When I use a screen resolution 1280x1024 Large Fonts (120 dpi), text on many web pages becomes unreadably small. Changing the browser.display.screen_resolution pref to 120 dpi or any other setting has absolutely no effect with either Modern or Classic skin. Shutting mozilla down and restarting after the pref change has no effect. I've tried various settings from 0 to 200 with no effect on either the mozilla UI or text size on any web page. The expected result is that text size on web pages is adjusted for the higher resolution.
dup of bug 5599 or bug 20391...?
Assignee: matt → ben
I think not. bug 5599 is about changing the UI for setting the pref. bug 20391 is about calculating dialog window sizes based on the pref. Neither of these is the problem. In the fonts prefs dialog, the description of Screen Resolution reads: "Choose a screen resolution. A larger value can improve text readability on some displays." The default value is 96 dpi. Changing this setting to 120 dpi has absolutely no effect on either the text size in the UI, nor the text size on any web page. Everything looks exactly the same regardless of the pref value, even after mozilla is shut down and restarted. I even tried a value 0 (bug 36894) in the off chance it would do something. Nada. If this pref has some purpose other that adjusting text size for the specified resolution, then the description in the pref dialog should be reworded to indicate what it really does, or document somewhere what its limitations are. If this pref does not apply to the Windows OS, then it should be removed or disabled in the Win32 prefs dialog. I haven't found a bug that indicates it's just plain busted on all OS's. Incidentally, the browser.display.screen_resolution pref is not listed in all.js or any other default/pref/ file. I went there first looking for a clue.
okay.
Status: UNCONFIRMED → NEW
Ever confirmed: true
mac needs 96 dpi default.
The value of the default is not being questioned. 96dpi is probably OK for the majority of Windows users as well. It just doesn't cut it when the screen resolution is actually something other than 96dpi, like 120dpi in my case.
Moving to preferences:backend...
Assignee: ben → dveditz
Severity: normal → minor
Component: Preferences → Preferences: Backend
Keywords: ui
Preferences: Backend is for the raw mechanism of getting and setting prefs. Please reassign this to whichever group ought to be interpreting this particular pref. Putting back the "Preferences" component who could solve the problem by removing the broken option, or else can forward on to whomever is supposed to be supporting the pref.
Assignee: dveditz → matt
Component: Preferences: Backend → Preferences
back to ben, for the nonce...
Assignee: matt → ben
While it does seem to be the case that browser.display.screen_resolution is ignored in the Win32 version, this probably isn't terribly important, because Mozilla calls GetDeviceCaps(..., LOGPIXELSY) to get the screen resolution from Windows. From what I can tell, the problem is that the default font size is specified in pixels, not points. If you load a page that uses CSS to specify a font size in some physical unit (0.5in, for example), you'll notice that the text is the right size. However, regular old text without any stylesheets uses the font size from the Fonts Preferences dialog, and contrary to expectations, those sizes are pixels, not points. I notice that nsPresContext::GetFontPreferences () looks at the font.size.unit pref to interpret font sizes that don't have an explicit unit--if I set it to "pt", my 133dpi screen is actually legible :) I don't know what the right fix for this is, but I do know that users don't want to specify font sizes in pixels: the font size set by the Fonts Preferences dialog should be in points. This probably explains why the Unix Xlib version seems to ignore the screen resolution setting too.
there's a bug to change the font preferences panel behavior, i'll encourage rbs to comment about it.
This pref should do something on at least Mac and Unix (it's arguable whether we should have it on Windows), and I know it used to work. It's currently implemented on the GTK, Mac, BeOS, Photon, QT, and Xlib ports. However, I can also say that it's currently broken on GTK.
We still have the problem that we won't pick up the pref changed callback after the first device context goes away. I'm still thinking about the best way to fix that...
Shouldn't the handling of this preference be in nsFontMetrics, since it applies mainly to fonts? Since it is in the fonts preference panel, I expect the size of fonts to change when I change this preference, but I don't expect the size of the dialogs and windows to also change. It seems to me that the latter is what some people are hinting at with regards to this pref. If it's only for fonts, then I would expect it to be handled in nsFontMetrics.
This is for anything sized in physical units. Our dialogs shouldn't have anything that uses physical units, and they really should never be used for screen media. This pref is a workaround for the fact that many Web authors don't know that.
why are you casting to (void*)?
Blocks: 79119
r=bryner
taking
Assignee: ben → dbaron
Target Milestone: --- → mozilla0.9.4
Status: NEW → ASSIGNED
Priority: -- → P3
*** Bug 89078 has been marked as a duplicate of this bug. ***
I think the long-term solution is to move the code implementing this into the cross-platform nsDeviceContext. However, I want to get attachment 46928 [details] [diff] [review] in to get this working for 0.9.4.
sr=waterson
Actually, I changed my mind about wanting to get this in for 0.9.4. It hasn't worked for a while, so we don't really know whether it does bad things or not. If anyone disagrees, I'll just push this out and try to come up with the real fix later...
Severity: minor → normal
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Oh, and I forgot to mention, I checked in the GTK fix (attachment 46928 [details] [diff] [review]) last night.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Slackware Linux with xfree86 4.1.0. install of 0.9.5 borked fonts and made then _really_ small.... I am using 1920x1440 screen resolution and it made the fonts completely unreadable. Going back to 0.9.4 with the same prefs.js works fine. 0.9.5 does not, i can deal with 0.9.4 for a while but Ctrl+T in 0.9.5 rocks my world... Btw, changing browser.display.screen_resolution does not do anything...
I don't understand this (it doesn't make sense), but the patch in attachment 46928 [details] [diff] [review], checked in as revision 1.80 of gfx/src/gtk/nsDeviceContextGTK.cpp, SOMEHOW caused (or at least triggered) bug 103145. Reversing the patch on the current version of the code in CVS "fixes" that bug, or more likely masks a deeper bug of some sort. I know it appears impossible on the surface. A seemingly-innocuous change to the SetDPI() calls in nsDeviceContextGTK.cpp somehow causes wildly inappropriate scaling values to be generated by gfx/src/ps/nsPostScriptObj.cpp when printing images to a PostScript file or printer. I wish someone could explain this, because currently I can't. It's very complex and difficult to backtrace where the values are coming from when printed, yet that bug is only exhibited when the patch for this bug is applied. I agree in advance that it's counterintuitive and it shouldn't happen, yet I have verified conclusively that it does. Can anyone here explain what's going on? (You might want to reference my notes under bug 103145 for more information...)
Depends on: 103145
I've determined that I can only replicate bug 103145 with settings from 71 dpi to 73 dpi; 70 dpi and under don't trigger that bug and neither do 74 dpi and up. Since the code from before this patch effectively left mozilla always using 96 dpi regardless of the setting of browser.display.screen_resolution, that bug was never seen until this one was fixed. I still don't know why this GTK code affects the PostScript printing, and I don't think this "screen resolution" value should affect printing size, but maybe that's another bug...
Priority: P3 → P1
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → Future
Mac build has same problem. FreeBSD build has no problem.
OS/2 offers a functional choice between "system setting", 96, & 120.
This probably should be changed from Win98 to all, since more than just it is affected. Comment 30 was made obsolete shortly after I made it. Mike Kaply made the OS/2 ports behave just like the Win ports, getting DPI from the system and ignoring the pref setting. RedHat/Fedora is badly impacted by the use of this pref. I filed a Fedora Core bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107803 even though some think the problem is Mozilla rather than RedHat/Fedora. In that bug's 1.4.1-7 http://www.mozilla.org/ screenshot attachments https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=95414&action=view and https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=95415&action=view you can see that some fonts (pt sized) are the same, while others (e.g. x-small) are _smaller_ at _higher_ DPI. http://www.mozilla.org/ uses points mostly for font sizing. Bad, bad, bad. Someone on the Mozilla.org payroll needs to point Ben Goodger (that page's author, already cc'd here, and who if I'm reading what I think I am in this bug's activity, was this bug's previous assignee) and Dave Shea (author of its tentative replacement) to comment 16, or find a new author that understands and uses it.
So what is the right fix here? Just hide the pref-UI for Mac, OS/2 and Windows? This should be easy with the XUL-preprocessor. Is there a way to get the system's resolution setting for all platforms? In this case I would vote for removing the pref altogether and always use the system's value, since Mozilla runs on the same display as all the other applications, or? ;-)
I have Windows XP, a very high resolution LCD (1920x1200), Gforce Go 5200, DPI set to 144. IE is working fine. Mozilla is basically unusable, because the fonts are microscopic. Changing the minimum font size in Mozilla to 24 or so produces a readable font, but web pages look horrible. I have tried various values for the display resolution in Mozilla. Nothing has any effect. Unfortunately, I have to go back to IE until this is fixed. Thanks.
Scott, which fonts are you having a problem with? Is what you see on XP different from this? What happens if you set XP to 168 (175%) or 192 (200%) DPI? I can't see much difference between IE and Mozilla. For us to see what you see we either need example URLs or screenshot(s) or both.
comment 33 and comment 34 are not related to this bug and should be discussed elsewhere.
Product: Browser → Seamonkey
This bug still exists in the Windows version of Firefox 1.0 (running under WinXP) (it does not affect the linux build). There are two issues here: first, that Firefox does not recognize the Windows system default resolution (set in Display Properties -> Settings -> Advanced -> General -> Font size); second, that even setting the "display resolution" setting in the Firefox preferences correctly and then restarting the browser still does not change either the UI font size or the page font size. This is not a problem with 1024x768 resolution, but on modern laptop SXGA screens (1400x1050) it makes Firefox basically unusable as the UI fonts are unreadably small. This is an issue that is going to become increasingly annoying as higher resolution screens become more popular! (In contrast, IE and other Windows applications detect the system DPI setting and display correctly.)
The problem described in this bug isn't that we don't detect the system display resolution; it's that we don't allow the user to override it.
> The problem described in this bug isn't that we don't detect the system display > resolution; it's that we don't allow the user to override it. Erm ... from the initial bug description: "The default value for pref browser.display.screen_resolution is 96 dpi. This is fine when using Windows Small Fonts, which is 96 dpi. When I use a screen resolution 1280x1024 Large Fonts (120 dpi), text on many web pages becomes unreadably small." i.e. the display resolution that the user had set (120 dpi) was not detected. Not detecting the system resolution is a problem; but not allowing the user to override it is a far bigger problem (as without the system display resolution being detected, the finer the resolution the more unreadable the UI fonts become). Personally it doesn't affect me as I use Linux, which scales the fonts just fine. But I had to recommend to a Windows user that they use IE over Firefox the other day simply because the Firefox interface font was impossibly small at 1400x1050, and that hurt! This issue isn't one that's going to go away - many laptops are now being made with SXGA screens and I'm sure desktop LCD monitors can't be far behind. (This is exactly the same problem as described in Comment 33) Is there any move to implement this feature in Windows? I notice in Comment 11 that the appropriateness of this preference option in Windows is questioned, without any explanation as to why it would not be usefull.
That statement in comment 0 is not true and has not been for a long time. nsDeviceContextWin::CommonInit initializes mPixelsToTwips based on ::GetDeviceCaps(aDC, LOGPIXELSY). It's only the pref that allows the user to override the system that's not implemented.
This bug still exists in 1.0.4 on Windows XP. User defined display resolution does nothing, as apparently it should according to the comments here, so remove the option from the fonts panel as it just confuses users! The second problem is that Windows users select fonts based on points, not pixels, so unless they read very closely, the font size selection doesn't do what they expect. This should be changed to Points in the Windows (and maybe all) version.
QA Contact: bugzilla → nobody
Blocks: 309103
Component: Preferences → GFX
Product: Mozilla Application Suite → Core
*** Bug 309103 has been marked as a duplicate of this bug. ***
FYI. Today, UI removed.(bug326329)
Product: Core → Core Graveyard
layout.css.dpi replaced browser.display.screen_resolution in bug 327406 so either this summary should be changed and bug 477213 duped to this, or this should be expired and bug 477213 confirmed. This applies also to W2K & WXP, not just Win9x.
versions supporting browser.display.screen_resolution have been out of support for years -> INVALID
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: