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)
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
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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.
Comment 6•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
Since you experience the problem and I don't, I assume what you're saying is
correct. setting dependency
Depends on: 43409
Comment 11•25 years ago
|
||
ahh this is a crasher too. I just tagged 43515 dup of 43409, but it seems they
both are dups of this one.
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
Even though this has been fixed, shouldn't there still be a check to make sure
that the value entered is reasonable?
Comment 14•25 years ago
|
||
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
Comment 15•25 years ago
|
||
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 → ---
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
*** Bug 43972 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
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 ago → 25 years ago
Resolution: --- → WORKSFORME
Comment 19•25 years ago
|
||
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
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•