115799 - crash if changing character coding to special "user defined"

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect)

Description

[Alexander Zink :alex]

From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en]C-CCK-MCD DT  (Windows NT 5.0; U)
BuildID:    20011120

Since I adjusted the fonts used for the "user defined" character coding, Mozilla 
crashes reproducible whenever I select "User Defined" from the menu "View" - 
"Character Coding" - "More".
Even after I set this back to the default value "Western (ISO-8859-1)", Moziall 
does no more display any sanserif-fonts. All fonts are converted to serif (looks 
like "Times New Roman") on all pages I visit. And also the "Fonts For" selection 
(in the Preferences - Fonts-Dialog) is empty by default (instead of showing my 
currently selected character coding set).

Reproducible: Always
Steps to Reproduce:
1. Open menu "Edit" - "Preferences" - "Appearance" - "Fonts"
2. Set the "Fonts for" value to "User Defined"
3. Leave "Proportional" as "Serif" (why can I not choose from all the fonts 
here???); set "Monospace" to "Courier New"; change all other font types to 
"Tahoma"
4. Click OK and leave the preferences dialog
5. Choose menu item "View" - "Character Coding" - "More" - "User Defined"
6. On my machine Mozilla crashes immediately. Even after a restart (when I have 
set the default back to "Western 8859-1", Mozilla displays all pages with serif 
fonts, even when they were correctly shown using a non-serif font before...

Actual Results:  Mozilla crashes;
displays pages incorrectly after problematic settings are set back to default

Expected Results:  Mozilla should have shown all pages using just the "Tahoma" 
font (or Courier New).
After reverting the settings back to default, Mozilla should behave as it did 
initially (displaying sansserif fonts as sansserif)

The crash dialog reports the following data (will try to translate):

"mozilla.exe - error in application"
The command in "0x6036dd4e" references the memory location "0x00000000". The 
command "read" could not be performed on the memory.

Comment 1

[sairuh (rarely reading bugmail)]

alexander, could you pls try this with a more recent build? thx!

Comment 2

[Samir Gehani]

Can't reproduce on a current Win2K build (2001121703).  Reporter, if you can
reproduce this with a current build from:
<http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/> please reopen this
bug with additional steps/conditions you may have.  Thanks for your time.

Comment 3

[sairuh (rarely reading bugmail)]

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 :)