Closed Bug 149417 Opened 18 years ago Closed 17 years ago

Treat US-ASCII as ISO-8859-1 (Meta chaset tag)

Categories

(Core :: Internationalization, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: momoi, Assigned: shanjian)

References

Details

(Keywords: dataloss, intl, topembed, Whiteboard: [adt2])

Attachments

(1 file)

** Observed with 2002-06-04 Win32 1.0 branch build **

There are a number of web pages which mistakenly label IS-8859-1 pages as
US-ASCII. While this is an evangelism issue, we can also alleviate this problem
by assuming that US-ASCI label is equivalent to ISO-8859-1. 
Assigning this to Shanjian who already worked on a similar NS-internal issues.

So far neither shanjian nor I believe that there will be bad side effects of doing
this and this will help resolve a number of evangelism issues in Latin Amartican
sites.
Keywords: intl
QA Contact: ruixu → ylong
Can you please give an example page?

pi
Marking topembed based in the AOLMAIL sites. Kat, let us know if you think this
one should be nsbeta1 also. Probably late in the game for this. 
Keywords: topembed
jaime, this is topembed for us. I would also like to nominate this
for nsbeta1. A lot of Latin American sites are affected by this 
problem.
Keywords: nsbeta1
Attached patch patchSplinter Review
frank, could you review?
Status: NEW → ASSIGNED
Should we change the charsetalias.property instead?
nsbeta1+ 
IF the site have this mislabel. we will lost data when we submit the form 
Blocks: 141008
Keywords: nsbeta1dataloss, nsbeta1+
Whiteboard: [adt2]
frank,
I worried about 2 side-effect if using charset alias. 
1, we don't want to affect unicode to ascii, only ascii to unicode.
2, We still want to mark the web page as us-ascii encoding even we treat it as
iso-8859-1. Otherwise, for a page that is really strict ascii, and it is labeled
so, we shouldn't mark it as iso-8859-1. 
if you don't treat them as ISO-8859-1 then what will happen when you sutmit a
form? the ISO-8859-1 characters will be lost in the form submission.
Yes, that's a strong argument. But if we do that, we may face complain about 
ascii document originated from our browser. 
Frank, a second thought. My patch should not have any problem in posting. If a
char could not be encoded in us-ascii, NCR will be used and result should be
fine. If we use alias, and if the charset is marked correctly as us-ascii, then
we will have problem in post because high ascii will be encoded in latin1
instead of NCR. 
(I tested this on my build, the hight ascii post works fine when charset is
us-ascii.)

Please r= and I will drive this in. 
Comment on attachment 88976 [details] [diff] [review]
patch

r=ftang
Attachment #88976 - Flags: review+
blizzard, could you sr?
shanjian: mgalli@netscape.com said it is important for us to fix this asap.
Please make this a high priority now.
Priority: -- → P1
Comment on attachment 88976 [details] [diff] [review]
patch

sr=alecf
Attachment #88976 - Flags: superreview+
shanjian, can we land this in asap ?
fix checked in. 
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Kat: is there some page labled as US-ASCII that I can use for verification? thanks!
Sent ylong the info on sites with this problem. 
After testing with them, please write down some URLs
in this bug also.
All right(TM)!
=============
 We tested with Kat Momoi, Doron and me with the AOLMAIL.aol.com.br looks super
great! this fixes the cases with Yahoo Brasil, AOLMAIL in Brazil, Mexico and
Argentina AOLMAIL as well. Additionally (I learned here) this prevents the
dataloss :) super thanks! Shanjian, Frank and Kat Momoi and all the others
involved. 
I also verified it on Argentina mail site by forword a message without a receiver.

Mark as veirified.

I think we should check this into branch as well.
Verified.
Status: RESOLVED → VERIFIED
Keywords: adt1.0.2
please consider taking this for the build for bug 168047. This is a very safe
fix. This fix has been land and verified on trunk already. 
Blocks: blackbird
Keywords: mozilla1.0.2
adt1.0.2+. Discussed in Blackbird team meeting. Please check in by close of
business today. 
Keywords: adt1.0.2adt1.0.2+
Comment on attachment 88976 [details] [diff] [review]
patch

a=chofmann for 1.0.2
Attachment #88976 - Flags: approval+
fix checked into branch.
Verified fixed in 10-21 branch build.
Marking as verified1.0.2 per Comment #28 From Yuying Long.
You need to log in before you can comment on or make changes to this bug.