** 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.

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.

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.

frank, could you review?

Should we change the charsetalias.property instead?

nsbeta1+ IF the site have this mislabel. we will lost data when we submit the form

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

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.

Comment on attachment 88976 [details] [diff] [review] patch sr=alecf

shanjian, can we land this in asap ?

fix checked in.

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.

Do this patch also fix bug 77741 ?

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.

adt1.0.2+. Discussed in Blackbird team meeting. Please check in by close of business today.

Comment on attachment 88976 [details] [diff] [review] patch a=chofmann for 1.0.2

fix checked into branch.

Verified fixed in 10-21 branch build.

Marking as verified1.0.2 per Comment #28 From Yuying Long.