104227 - JS write() including some charset causes Error: uncaught...

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[chado]

I'm not sure about Component. 

JS document.write() with meta statement including some charset causes Error. 
Meta statment means like this:
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
JavaScript Console says:
  Error: uncaught exception: 
  [Exception... "Component returned failure code: 0x804e03f7[nsIDOMNSHTMLDocument.write]" 
   nsresult: "0x804e03f7 (<unknown>)" .....]
Then, nothing is rendered.  

I tried some charsets. ( http://www2.wbs.ne.jp/%7Echado/work/js_write/js_write.html )
ISO-8859-1, Shift-JIS and x-sjis are OK.
EUC-JP, Shift_JIS, ISO-2022-JP and x-euc-jp are OUT.

Reproducible : Always
Build : Mac 2001-09-28-08-trunk works fine. 
        Mac 2001-10-01-08-trunk and after including 2001-10-10-08-trunk don't.
        Win32 2001-09-28-16-trunk works fine.
        Win32 2001-09-29-11-trunk and after including 2001-10-10-09-trunk don't.

For reference: In Japan, EUC-JP, Shift_JIS, or ISO-2022-JP are preferred. 
               And Shift-JIS is known as invalid.

Comment 1

[Phil Schwartau]

Reassigning to Internationalization. Is this another duplicate of 
bug 63626 "Charset decoding silently fails for JavaScript files" ?

Comment 2

[Frank Tang]

nhotta- can you take a look at this one ?

Comment 3

[Andreas Becker]

Switching QA contact to teruko for now.

Comment 4

[nhottanscp]

2001-09-28-16-trunk/ works, 2001-09-29-11-trunk/ does not work.

Checkins between 09/28/2001 16:00 and 09/29/2001 11:00 : 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&bra
nchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&d
ate=explicit&mindate=09%2F28%2F2001+16%3A00%3A00&maxdate=09%2F29%2F2001+11%3A00%
3A00&cvsroot=%2Fcvsroot

Comment 5

[nhottanscp]

nsbeta1+
regression

Comment 6

[nhottanscp]

Reassign to harishd.
On 9/28, there was a change for bug 96364 which includes changes for META
charset related code.
I pulled a build of09/28/2001 17:00 and backed out of the changes of bug 96364
then I the example works fine.
http://www2.wbs.ne.jp/%7Echado/work/js_write/js_write.html

I don't know what part of the change cause this regression, cc to shanjian.

Comment 7

[harishd]

Out of time --> 0.9.8

Comment 8

[harishd]

The JS error is thrown because an error message (
NS_ERROR_HTMLPARSER_STOPPARSING  ) got propagagted to xpcwrappednative. That
could be fixed. But the link still doesn't work correctly!. Not sure what's
causing the problem. 

FYI: The URL ( http://www2.wbs.ne.jp/%7Echado/work/js_write/js_write.html )
works fine in viewer. I really doubt this is a parser bug. 

Johnny?

Comment 9

[Johnny Stenback (:jst)]

Harish, do you have a fix for the error message that's incorrectly propagated to
the caller of document.write()?

Comment 10

[harishd]

Attachment: patch v1.0 [ don't propagate error msg to xpcwrappednative ]

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 63314 [details] [diff] [review]
patch v1.0 [ don't propagate error msg to xpcwrappednative ]

sr=jst

Comment 12

[harishd]

Attachment: patch v1.1 [ No need to notify tag observers when document.writing ]

Comment 13

[harishd]

Please ignore my last patch. This would probably regress editor. IMO, the
current behavior ( not displaying content ) is the correct behavior! But will
have to find out what was happening prior to 9/28. Shanjian, any clues?

Comment 14

[harishd]

Out of time. Mass move to 0.9.9

Comment 15

[harishd]

patch v1.0 is in. This should fix the JS error. 

Comment 16

[Shanjian Li]

I checked this with current trunk build, and here is my understanding of what's happening.

The default charset for js write document is iso-8859-1. During the loading of this js 
write document, meta charset is found. If meta charset specified is different from 
current charset (iso-8859-1), document will be reloaded through "nsDocShell::Reload". 
In turn "LoadHistoryEntry(mOSHE, type)" is called to reload the document. The uri of 
the history entry is the same as the original html url 
(ie. http://www2.wbs.ne.jp/%7Echado/work/js_write/js_write.html), thus nothing rendered in 
child frame.

There are 2 problems in this scenario,
1, Mozilla obviously failed to reload js written document. Choose iso-8859-1 charset, and 
  child frame will be rendered correctly. If you select "Reload frame" from context menu, 
  blank page will be displayed. This is a problem need to be fixed or we have to forbid
   reloading from happening for js write() document. (Is there an existing bug for this?)
2, Mozilla should not honor meta charset reload for js write doc. 
  We should assume every piece of text have been converted to unicode in parser when the 
  original document is loaded. I did some test with IE, and they are doing this. If I 
  put some euc-jp text in js write document, no matter what meta charset I specified for 
  child frame, display is always correct. Netscape4.x did things totally wrong, it could 
  not display the text correctly any way.  

  Harish, can you fix item 2 in this bug? Item 1 is probably beyond your scope and we should 
file another bug for that. What do you think? 

Comment 17

[harishd]

>Harish, can you fix item 2 in this bug?
Refer to #12.

Comment 18

[Shanjian Li]

patch 1.1 might be too general. We only need to disable meta tag observation for 
js document write. That way you won't have editor regression. 

Comment 19

[harishd]

I don't think there is a way to know if the data is document.written ( have to
double check though ). Is it possible for the charset observer to not reload
somehow?

Comment 20

[Shanjian Li]

I looked into a little bit more, but could not find a solution. Meta charset
observer have no idea about if this is js document write either. 

Who do the conversion for network data, is it parser? Clearly in this case, 
parser does not bothering with any conversion at all. (charset set in parser 
is the default iso-8859-1). An alternative solution might be the place where 
parser is created. If the caller know this is for js doc write, it could set 
parser's charset source to "kCharsetFromOtherComponent" using 
"nsParser::SetDocumentCharset". That will disable meta charset observer from 
making any notification. "nsHTMLDocument::Open(nsIDOMDocument** aReturn)" or 
"nsHTMLDocument::OpenCommon(nsIURI* aSourceURL)" might be start point for 
tracing such a position to add the call. Somebody familar with js doc write 
load need to offer some help. 

Comment 21

[harishd]

Apparently fix for bug 118404 has fixed this bug too! 

Since the JS error problem has been fixed. Marking this bug fixed.

Comment 22

[chado]

just for note:
We are still seeing some META-charset related problems after 
this bug has been marked as FIXED.  bugs that I've filed are: 

bug 125315 "JS write() including charset display characters inccorectly"
bug 125317 "JS write() including charset makes forms uncontrollable"
bug 125767 "JS write() with some META-charset don't render contents"

Comment 23

[Teruko Kobayashi]

Verified as fixed in 2002-02-26-03 trunk build.