Closed Bug 43264 Opened 25 years ago Closed 25 years ago

After changing font mozilla can't launch the Preference window a second time

Categories

(SeaMonkey :: Preferences, defect, P3)

x86
Linux

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: kfir.shay, Assigned: matt)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.15-4mdk i686; en-US; m16) Gecko/20000620 BuildID: 2000062008 After changing serif font mozilla can't lunch the Preference window a second time so I cange the font back to what it was. also after the change if I close mozilla and try to lunch it again I can't view web pages at all. Reproducible: Always Steps to Reproduce: 1.lunch Mozilla open Preferences window go to fonts change serif font to something else. 2.close Preferences. 3.Open Preferences again, but you won't be able to see anything.
The bug is confirmed, and here is the problem: When you change the font preference, the default dpi in the dialog box is 9696, instead of 96. The bug is fixed simply by changing the number to a more sensible one. So maybe someone should see why the default became 9696 by mistake. Also, maybe there should be a sanity check on the value entered there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
odd, i cannot repro this using 2000.06.21.08 [opt commercial] on linux. the font resolution remains 96, nor is the Prefs dialog blank the second time i open it.
i [partially] take back my comment above... i did see the 9696 for dpi when using the win32 [same bits, but on winNT]... however, i still don't see the prefs dialog going blank the second time opening it.
I see the 9696 also...the problem that some pref panes appear empty is a separate bug, and is a redrawing problem...moving the dialog off screen and then back on or covering it with another app and then moving the app should fix the problem..
Summary: After changing font mozilla can't lunch the Preference window a second time → After changing font mozilla can't launch the Preference window a second time
I still see the bug on 2000062108 on Linux. Also, I don't think the original report was about "some prefs pane", but *all* prefs pane. Trying to get the window to redraw did not help at all for me.
In that case, I don't see the disappearing problem you're describing.
To be totally precise, here is what happens when I opened the prefs window again after changing the fonts. I get the prefs window frame popped up, but there is nothing in the frame: the content of the window is just whatever it is that's behind the window.
hchcheng@scg.math.uwaterloo.ca -- are you sure that the problem that prefs don't show up is dependent on the fact that the default font dpi is 9696? And how do you know? If that is, indeed, the case, I'm going to leave this bug as "preferences don't show up" (which I don't even see) and make it dependent on bug 43409, "default font dpi is 9696"...then we'll see if both get fixed when the time comes.
I know that if this problem occurs only if I leave the dpi as 9696. If I change it to 96 instead, there is no more problem. I think this is the problem.
Since you experience the problem and I don't, I assume what you're saying is correct. setting dependency
Depends on: 43409
ahh this is a crasher too. I just tagged 43515 dup of 43409, but it seems they both are dups of this one.
i had the same prob (pref's not appearing correct when opened second time after the 9696 bug had written to prefs.js.) It's solved now - screen resolution is back to 96 - god knows what happened. Prefs now open OK. Linux 2000-062321.
Even though this has been fixed, shouldn't there still be a check to make sure that the value entered is reasonable?
hchcheng@scg.math.uwaterloo.ca, that should be a separate bug. marking wfm based on dark@c2i.net's comments (fwiw, it also defaults to 96 for me in 26408, though I never saw the prefs problem so I can't confirm that).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
it's back - 9696 now default on linux 062914 Reopening this one too since there's trouble ahead till it gets fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm probably completely wrong but could this have anything to do with bug 42178 -back or reload casues corruption in forms (it appends the contents of the form a second time). I know it's probably not related but thought I'd comment since it's doubling up the 96 -just in case.
*** Bug 43972 has been marked as a duplicate of this bug. ***
marking WFM again - fun bug - comes and goes :) It's worked for a while again. currently OK on linux build ID 2000-072113.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → WORKSFORME
feel free to verify these (or reopen, if still a problem) if i don't get around to it beforehand. if you do so, pls do remove the verifyme keyword after verifying a given bug. thx!
Keywords: verifyme
verified, works for me.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.