Closed Bug 97606 Opened 24 years ago Closed 24 years ago

Default character coding setting is blank in pref

Categories

(SeaMonkey :: Preferences, defect, P3)

Product:
SeaMonkey
Component:
Preferences
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: doctor__j, Assigned: tao)

References

Details

(Keywords: regression, Whiteboard: PDT+)

Attachments

(6 files)

Screenshot
12.64 KB, image/png
Details
Screenshot (repost)
43.89 KB, image/gif
Details
reverting intl.charset.default pref default to the platform-independent navigator.properties file
924 bytes, patch
Details | Diff | Splinter Review
mozilla: add navigator.proeprties to en-{win,mac}.jar
18.63 KB, patch
dveditz
: review+
alecf
: superreview+
Details | Diff | Splinter Review
ns: register navigator-platform
2.31 KB, patch
tao
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
(revised) mozilla: add navigator.proeprties to en-{win,mac}.jar
16.71 KB, patch
tao
: review+
tao
: superreview+
Details | Diff | Splinter Review
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)".
Attached image Screenshot —
-> jbetak? interestingly, i see this on mac and windows [regardless of theme], 2001.08.29-comm, but *not* on linux.
Assignee: sgehani → jbetak
Keywords: mozilla0.9.4, regression
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?
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
Read my repro steps #1: Create a new profile.
Attached image Screenshot (repost) —
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.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 98631 has been marked as a duplicate of this bug. ***
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.
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?
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.
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?
Whiteboard: have patch - need r/sr/a
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.
Bad regression. Nominating for nsbranch 0.9.4.
Keywords: nsbranch
Target Milestone: mozilla0.9.5 → mozilla0.9.4
marking nsbranch+, bad regression
Keywords: nsbranch → nsbranch+
per our offline discussion - reassigning to tao. Tao, please let me know if I can be of any assistance.
Assignee: jbetak → tao
Status: ASSIGNED → NEW
Comment on attachment 49056 [details] [diff] [review] ns: register navigator-platform sr=dveditz
Attachment #49056 - Flags: superreview+
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
Attachment #49055 - Flags: review+
*** Bug 97705 has been marked as a duplicate of this bug. ***
Nomintae for PDT
Status: NEW → ASSIGNED
Whiteboard: have patch - need r/sr/a → PDT; have patch - need r/sr/a
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Blocks: 97997
No longer blocks: 97997
This would block bug# 97997 - the page https://easyweb.tdcanadatrust.com fails to load when the charset is set to blank.
*** Bug 98908 has been marked as a duplicate of this bug. ***
This still needs an R for one patch, and SR for another patch. Pls get this one ready.
The new files you mentioned are in fact exact copies of some old files. I'll resubmit a patch without the jar.mn~.
Whiteboard: PDT; have patch - need r/sr/a → PDT; need r/sr
r=jbetak I'm just wonderign: do the Mac-specific files need to be added to Codewarrior project files?
Tao - How close are we to getting an SR.
thanks for the review. No, you don't need to update project files for chrome files addition.
Whiteboard: PDT; need r/sr → PDT; need sr
Comment on attachment 49056 [details] [diff] [review] ns: register navigator-platform per jbetak 2001-09-18 16:03
Attachment #49056 - Flags: review+
note: tested on both win and mac.
Comment on attachment 49055 [details] [diff] [review] mozilla: add navigator.proeprties to en-{win,mac}.jar seems reasonable to me! sr=alecf
Attachment #49055 - Flags: superreview+
Comment on attachment 49714 [details] [diff] [review] (revised) mozilla: add navigator.proeprties to en-{win,mac}.jar r=dveditz,sr=alecf
Attachment #49714 - Flags: superreview+
Attachment #49714 - Flags: review+
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.
Whiteboard: PDT; need sr → PDT;
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
check it into the branch and trunk - PDT+
Whiteboard: PDT; → PDT+
Whiteboard: PDT+ → PDT+, (in trunk)
Blocks: 99108
Check this in on the branch now.
*** Bug 100370 has been marked as a duplicate of this bug. ***
*** Bug 100925 has been marked as a duplicate of this bug. ***
in branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: PDT+, (in trunk) → PDT+
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
*** Bug 101568 has been marked as a duplicate of this bug. ***
vrfy fixed on winnt, mac os 9.1 and mac os 10.0.4 --using 2001.09.25-branch comm bits.
Keywords: vtrunk
vrfy fixed using 2001.10.22.1x-trunk comm bits on linux rh6.2, mac 10.1 and winNT.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: