Please report any other irregularities here.
Linux build 2000070508 (but I've been seeing this since day 1). Go into Edit|Prefs, change font resolution from 96 to 120. Click OK. Results: Clicking Edit|Prefs again, the text is now too large to fit in a panel. Changing font size has no effect on this.
the preferences dialog can be manually resized to fit its contents like any other resizable window.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
No it can't ! At least not under my version of Enlightenment. This is not an invalid bug.
i actually had to go to 240dpi before i ran into this problem, but now i can't get back to the dpi entry box, so i'm stuck with huge fonts! where is the pref so i can tweak it by hand?
user_profile_dir\prefs.js: user_pref("browser.display.screen_resolution", 96); Mozilla should pop up a warning for any setting over 96dpi. Window resizability depends on screen display resolution. Interestingly on Win32 070708 the font dpi setting has no effect.
Why should mozilla pop up a warning for a resolution over 96 ? Either a resolution > 96 is invalid, in which case the user should be prevented from doing so, or it is valid, in which case the prefs panels should ignore the setting, use the font size specified by the user, or resize themselves accordingly.
>96 dpi is definitely valid. The reason Mozilla should warn the user is because the fonts can become so large (i.e. try a 400dpi) that it will be impossible to readjust the setting back down to 96 via the prefs dialog. The user needs to be aware of that. A warning would do just that. Want proof? set dpi to 400. This is why we need a warning. Reopening bug & updating summary.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Changing font resolution to 120dpi horks prefs panels → Large font dpi setting makes Mozilla unusable, impossible to adjust back down to a smaller dpi thru preferences
yep, i tried setting the dpi to 400, and did it look awful. there's the workaround of fixing this by editing the prefs.js line back to 96: user_pref("browser.display.screen_resolution", [dpi_number]); confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also bug 43742, which was a response to a few bugs when the default dpi was accidentally set to 9696 a while ago.
Seems a bit lame to give a warning...can't the prefs window resize itself ? (I'm assuming od course that 43742 is resolved so that ridiculous values are not allowed.)
Large values may be useful for someone with impaired eyesight. I don't think balking at them is a wise move unless cut it off at a high value like 800dpi. However, this can be resolved by make the prefs window scrollable and resizable rather than just resizable. I'm fortunate I have a 1600x1200 display, but on an 800x600. My ((float)2/(float)100) worth... make it scrollable that would solve this problem.
I can verify this can be a problem...
For bug 43742, an extremely large dpi value was entered and it wasn't just that I get large fonts. In fact, I don't get anything at all. Starting Mozilla just gives an empty window frame with the content being whatever is supposed to be behind the window (in Linux). I don't mind getting huge fonts, but I have a problem if the only way to fix this is to edit prefs.js
Can't reproduce this on Linux Build ID - 2000073108
Yes, on the latest Linux build, the largest dpi value I can enter is 999, so at least it doesn't crash (but gives some very big letters and almost impossible to change back).
*** Bug 43742 has been marked as a duplicate of this bug. ***
This is no longer reproducible on 2001041308. Can anyone else confirm?
i cannot repro this using 2001.09.11.05-br bits. pls reopen with a test case if this is still an issue with recent bits.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 17 years ago
Resolution: --- → WORKSFORME
mass verification of WorksForMe bugs: to find all bugspam pertaining to this, set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM". if you think this particular bug is *still* an open issue, please make sure of the following before reopening: a. that it's still a problem with ***recent trunk builds*** on the all appropriate platform[s] b. provide clear steps to reproduce (unless a good test case is already in the bug report), making sure it pertains to the original problem (avoid morphing as much as possible :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.