125315 - JS write() including charset display characters inccorectly

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[chado]

This problem appeared after bug 104227 was fixed.

JS document.write() with meta statement including some charset display 
characters, depend on charset, incorrectly.
Meta statment means like this:
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Shift_JIS">
Japanese characters are displayed incorrectly, 
although English characters are displayed correctly.

I have testcases:
http://www2.wbs.ne.jp/%7Echado/work/js_write2/js_write2_sjis.html (Shift_JIS).
http://www2.wbs.ne.jp/%7Echado/work/js_write2/js_write2_euc.html (EUC-JP).
note: these testcases require Japanese language supported system with
      Japanese fonts. What should be seen are in it.  
In these testcases, Japanese characters are displayed correctly only when 
no charset was included.  NC4.79-us for mac9 renders correctly in all cases.
I've not tested other charsets since I don't have environment for those.

Reproducible : Always.
Builds I've tried:
  Mac9  2002-02-04-08-trunk, 2002-02-11-08-trunk. 
  Win98 2002-02-04-11-trunk, 2002-02-12-10-trunk.

Comment 1

[Frank Tang]

it happen in my 2002012806 window build. I think we should take a look at it. It
may represent some common JavaScript usage. 

Comment 2

[Frank Tang]

The biggest problem is all the text write to the document AFTER the meta won't
be display. 
4.x work. Not sure about n6.0 or n6.1. teruko, please try it.
nsbeta1+

harishd, is this related to your change several monthes ago?

Comment 3

[harishd]

Ftang: What change are you  referring to?

Comment 4

[chado]

2001-09-28-16-trunk on win98 works fine. That build is the 
last one (that I have) before the bug 104227 has appeared.  
Also N6.1J, N6.2J and N6.2.1J (commercial) work fine so far.  

I've re-written testcase : 
http://www2.wbs.ne.jp/%7Echado/work/js_write2_2/js_write2_sjis.html 
and have confirmed that ISO-8859-1 works. 

Ftang: I'm worrying about that 2002012806 should be showing different 
  behavior from what I'm seeing.  same about bug 125317.  sorry if not so.  

Comment 5

[Roy Yokoyama]

I don't think I am the right owner for this.
harishd/shanjian: can either of you take ownership of this?

Comment 6

[Roy Yokoyama]

looking at 104227, assiging to original owner-harishd

Comment 7

[Teruko Kobayashi]

This is regression from NS 6.21.

Comment 8

[Frank Tang]

harishd, this bug only include unit test example. For real life example at the
bug 122507 for real usage.

Comment 9

[Frank Tang]

harishd, I think I know what happen here. Hope you don't mind I move this bug back.

Comment 10

[Frank Tang]

patch will be post today

Comment 11

[Frank Tang]

see patch in 125317

Comment 12

[Frank Tang]

reassign back to harishd, please fix it whenever you can. 

Comment 13

[Jaime Rodriguez, Jr.]

This sounds like it might effect our embedding efforts international as well.
Adding topembed. Pls correct ME, if I am incorrect with a hearty minus or
clearing the keyword.

Comment 14

[Frank Tang]

heikki and harishd, could you put priority on this one ? I think this is a adt2 bug

Comment 15

[harishd]

FYI: I'm working on a solution that would target only document.writes. 

Comment 16

[Frank Tang]

This bug is blocking my adt1 bug 

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

If so, then please mark the dependency and add adt1 to status whiteboard.

Comment 18

[Frank Tang]

I ask hekki and harishd put adtxxx on status several times. Due to lack of
action, I put [adt1] on the status board for now since it block adt1 bug 122057

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think you meant bug 122507.

Comment 20

[Frank Tang]

the patch v1.5 in 125317 fix this problem . 

Comment 21

[harishd]

Frank: So can we mark this bug a dupe of bug 125317?

Comment 22

[harishd]

Closing the bug based on ftang's comment ( #20 )

Comment 23

[Teruko Kobayashi]

Verified as fixed in 4-22 trunk build.