97606 - Default character coding setting is blank in pref

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P3)

Description

[doctor__j]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010830
BuildID:    2001083005

Reproducible: Always
Steps to Reproduce:
1. Create a new profile.
2. Open Pref Menu -> Navigator -> Languages
3. Look at "Character Coding" section.
4. Default character coding setting is blank.  It should be "Western (ISO-8859-1)".

Comment 1

[doctor__j]

Attachment: Screenshot

Comment 2

[sairuh (rarely reading bugmail)]

-> jbetak?

interestingly, i see this on mac and windows [regardless of theme],
2001.08.29-comm, but *not* on linux.

Comment 3

[[e-mail] (away - not reading bugmail)]

hmm, interesting - doctor__j could you repost the screenshot please? For some 
reason, I can't see it. Have you tested this with a fresh profile?

Comment 4

[doctor__j]

Read my repro steps #1: Create a new profile.

Comment 5

[doctor__j]

Attachment: Screenshot (repost)

Comment 6

[[e-mail] (away - not reading bugmail)]

thanks doctor__j (and thanks for being so polite too).

This looks like a regression from my 08/16/2001 checkin, it starts with the 
08/17/2001 build. I think this is pretty bad - seems like 0.9.4 will ship like 
this, unless we get an emergency approval. I'll work on a patch and email asa 
and the drivers.

Comment 7

[sairuh (rarely reading bugmail)]

*** Bug 98631 has been marked as a duplicate of this bug. ***

Comment 8

[[e-mail] (away - not reading bugmail)]

OK, I'm getting closer: tao has checked in a change on August 28, which moved 
the default charset pref pref from "chrome://navigator/locale/navigator
.properties" to "chrome://navigator-platform/locale/navigator.properties". 

Cc'ing tao to solicit feedback - I think I'll have a patch in few minutes.

Comment 9

[[e-mail] (away - not reading bugmail)]

I'm currently testign Linux. I don't think it should appear there... 

Tao, do we need win/navigator.properties and mac/navigator.properties to make 
sure we find the pref default values on these platforms?

Comment 10

[[e-mail] (away - not reading bugmail)]

OK, this happens on Win and Mac only, since we don't have platform-specific 
navigator.properties files for these OSes yet.

At this point I see two ways to resolve this bug:

1) Create platform-specific navigator.properties for both Mac and Windows. If 
they are going to live in a separate jar file (I believe the Unix case sets a 
precedent here), it would require  an installer change. I think it's too late 
to get these kind of changes into 0.9.4, so we'd have to ship with a broken 
pref default for Win and Mac.

2) Revert the intl.charset.default location reference in all.js 
to "chrome://navigator/locale/navigator.properties". THis is a fairly minor 
change and could be slipped into the 0.9.4 build.

Comment 11

[[e-mail] (away - not reading bugmail)]

Attachment: reverting intl.charset.default pref default to the platform-independent navigator.properties file

Comment 12

[[e-mail] (away - not reading bugmail)]

tao, what do you think? Would this break the thing you tried to fix on Linux? 
Would shipping 0.9.4 with a broken pref default be worse than what gets broken 
by this patch?

Comment 13

[tao]

Looks like the description of 
http://bugscape.netscape.com/show_bug.cgi?id=8124 is not accurate:

  "Currently, intl.charset.default is set to Shift_JIS for Win and mac, but for
  linux it should be set to EUC-JP. This preference should be set in ja-unix.jar,
  since it affects only linux."

This prefs should be platform-dependent instead of unix-only. Please make the 
real fix in both branches but 

  1) for 0.9.5, check it in after r/sr.
  2) for 0.9.4, hold the change until moz0.9.4 is released.

Feel free to ask me for review or reassign to me if you like. 

Comment 14

[bobj]

Bad regression.  Nominating for nsbranch 0.9.4.

Comment 15

[msanz]

marking nsbranch+, bad regression

Comment 16

[[e-mail] (away - not reading bugmail)]

per our offline discussion - reassigning to tao. Tao, please let me know if I 
can be of any assistance.

Comment 17

[tao]

Attachment: mozilla: add navigator.proeprties to en-{win,mac}.jar

Comment 18

[tao]

Attachment: ns: register navigator-platform

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 49056 [details] [diff] [review]
ns: register navigator-platform

sr=dveditz

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 49055 [details] [diff] [review]
mozilla: add navigator.proeprties to en-{win,mac}.jar

>Index: xpfe/browser/resources/locale/en-US/mac/Makefile.in
>===================================================================
>+# The contents of this file are subject to the Netscape Public
>+# License Version 1.1 (the "License"); you may not use this file

This should probably be the Mozilla license unless this entire file is
copied from elsewhere. In any case the copyright date needs updating

>Index: xpfe/browser/resources/locale/en-US/mac/jar.mn~
>===================================================================
>RCS file: jar.mn~
>diff -N jar.mn~

Please don't check in backup files. If this is showing up in a "cvs diff -N"
then you must have done a "cvs add" on it. Be careful and don't commit this.

>Index: xpfe/browser/resources/locale/en-US/win/Makefile.in
>===================================================================
>+# The contents of this file are subject to the Netscape Public

Ditto license comments above. Other files in this patch use the
Mozilla license and the correct copyright date.

With the above caveats, r=dveditz

Comment 21

[tao]

*** Bug 97705 has been marked as a duplicate of this bug. ***

Comment 22

[tao]

Nomintae for PDT

Comment 23

[Asa Dotzler [:asa]]

0.9.4 is out the door.

Comment 24

[Rangan Sen]

This would block bug# 97997 - the page https://easyweb.tdcanadatrust.com fails
to load when the charset is set to blank.

Comment 25

[Darin Fisher]

*** Bug 98908 has been marked as a duplicate of this bug. ***

Comment 26

[Jaime Rodriguez, Jr.]

This still needs an R for one patch, and SR for another patch. Pls get this one
ready.

Comment 27

[tao]

The new files you mentioned are in fact exact copies of some old files. I'll
resubmit a patch without the jar.mn~.

Comment 28

[tao]

Attachment: (revised) mozilla: add navigator.proeprties to en-{win,mac}.jar

Comment 29

[[e-mail] (away - not reading bugmail)]

r=jbetak

I'm just wonderign: do the Mac-specific files need to be added to Codewarrior 
project files?

Comment 30

[Jaime Rodriguez, Jr.]

Tao - How close are we to getting an SR.

Comment 31

[tao]

thanks for the review. No, you don't need to update project files for chrome
files addition.

Comment 32

[tao]

Comment on attachment 49056 [details] [diff] [review]
ns: register navigator-platform

per jbetak 2001-09-18 16:03

Comment 33

[tao]

note: tested on both win and mac.

Comment 34

[Alec Flett]

Comment on attachment 49055 [details] [diff] [review]
mozilla: add navigator.proeprties to en-{win,mac}.jar

seems reasonable to me!
sr=alecf

Comment 35

[tao]

Comment on attachment 49714 [details] [diff] [review]
(revised) mozilla: add navigator.proeprties to en-{win,mac}.jar

r=dveditz,sr=alecf

Comment 36

[tao]

I'll see if I nedd to revise the license statement in the new files. If so, I'll
provide diffs (of the license statement) and then check it in.

Comment 37

[tao]

Based on the email discussion with Gerv, I am checking in the patches as it is.
thx!

--Q--
How do we handle exact copy of existing files? I am adding a few
directories/files into the tree. The new files are in fact exact copies of some
existing files in the tree. While some of these files have MPL, the others do
not have any license at all. Should I insert the triple license boilerplate into
those that don't have licenses yet? (Please refer the patches in
http://bugzilla.mozilla.org/show_bug.cgi?id=97606).

--A---
Unless the files are under the NPL, they should keep their original licenses. If
they have no license, then they should (for the moment) continue to have no license.

Gerv

Comment 38

[Jaime Rodriguez, Jr.]

check it into the branch and trunk - PDT+

Comment 39

[Jaime Rodriguez, Jr.]

Check this in on the branch now.

Comment 40

[Asa Dotzler [:asa]]

*** Bug 100370 has been marked as a duplicate of this bug. ***

Comment 41

[Waheed Islam]

*** Bug 100925 has been marked as a duplicate of this bug. ***

Comment 42

[tao]

in branch.

Comment 43

[Hong Kwon]

testcase for this bug:

1) visit http://www.paymybills.com
2) click on "Secure Login"

Expected Results

You get a login screen

Actual Results (in unpatched build)

You get "server 500" error

Comment 44

[Ashley Bischoff (blog at handcoding.com)]

*** Bug 101568 has been marked as a duplicate of this bug. ***

Comment 45

[sairuh (rarely reading bugmail)]

vrfy fixed on winnt, mac os 9.1 and mac os 10.0.4 --using 2001.09.25-branch comm
bits.

Comment 46

[sairuh (rarely reading bugmail)]

vrfy fixed using 2001.10.22.1x-trunk comm bits on linux rh6.2, mac 10.1 and winNT.