Closed Bug 125317 Opened 23 years ago Closed 23 years ago

JS write() including charset makes forms uncontrollable

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: chado_moz, Assigned: harishd)

References

Details

(Keywords: intl, regression, topembed+, Whiteboard: [adt1][fixed on the trunk 04/18 and branch 04/19])

Attachments

(1 file, 4 obsolete files)

patch v1.5 [ includes jst's suggestions ]
10.90 KB, patch
ftang
: review+
harishd
: superreview+
jesup
: approval+
Details | Diff | Splinter Review
This problem appeared after bug 104227 was fixed. JS document.write() with meta statement including some charset displays forms correctly (when Japanese characters are not contained). Meta statment means like this: <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Shift_JIS"> But these forms are uncontrollable from JS. I have a testcase: steps to reproduce: 1) go to http://www2.wbs.ne.jp/%7Echado/work/js_write3/js_write3_sjis.html . TEST1 for example. 2) click "no charset" link under TEST1. called JS don't write meta statment including charset. textbox of form containing "initial" appeares lower frame. 3) click "change value" link under TEST1. value of textbox changes to "changed". 4) click "EUC-JP" or "Shift_JIS" link under TEST1. called JS write meta statment including charset. textbox of form containing "initial" appeares lower frame again. 5) click "change value" link under TEST1. expected result: value of textbox changes to "changed". actual result: value of textbox is not changed. JavaScript Console says: Error: uncaught exception: Permission denied to set property HTMLInputElement.value steps for TEST2, TEST3 and TEST4 are similar to TEST1. NC4.79-us for mac9 and NC4.7-ja for win98 work fine in all cases. Reproducible : Always. Builds I've tried: 0.9.8 is not useable since 104227 blocks this. Mac9 2002-02-04-08-trunk, 2002-02-11-08-trunk. Win98 2002-02-04-11-trunk, 2002-02-12-10-trunk.
Keywords: intl
QA Contact: ruixu → teruko
this could represent common JavaScript usage. mark this as nsbeta1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
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?
Keywords: nsbeta1 → nsbeta1+
Status: NEW → ASSIGNED
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_write3_2/js_write3_sjis.html and have confirmed that ISO-8859-1 works.
I don't think I am the right owner of this. harishd/shanjian: can either of you take ownership of this?
looking at 104227, assiging to original owner-harishd
Assignee: yokoyama → harishd
Status: ASSIGNED → NEW
Keywords: 4xp
This is regression from NS 6.21.
Keywords: regression
harishd, this bug only include unit test example. For real life example at the bug 122507 for real usage.
Blocks: 122507
harishd, I think I know what happen here. Hope you don't mind I move this back.
Assignee: harishd → ftang
Attached patch patch v1. (obsolete) — — Splinter Review
when we received data from document.write, we should remember in the parser that the data is pass in in UTF-16 and the source is from other componenets so later on when we hit meta tag, we won't try to reload it.
Blocks: 104056
Status: NEW → ASSIGNED
reassign back to harishd, please fix it whenever you can.
Assignee: ftang → harishd
Status: ASSIGNED → NEW
No longer blocks: 104056
harishd, do you have eta for this ? 122507 is depend on this fix. It is a real usage in sina.com.cn
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.
Keywords: topembed
heikki and harishd, could you put priority on this one ? I think this is a adt2 bug
Keywords: topembed → topembed+
FYI: I'm working on a solution that would target only document.write.
>FYI: I'm working on a solution that would target only document.write. what OTHER cases will also pass though this code ?
Attached patch patch v1.2 (obsolete) — — Splinter Review
document.write content is already in unicode and therefore there is no need to notify the charset observer. However, the decision to load a new charset should actually happen in the charset observer and for that the charset observer should be informed about the document.write case. For simplicity, the content sink now ( with the patch ) makes the decision for the charset observer ( hopefully other observers don't get affected by this ). FYI: Going to work on the cleaner solution too.
Attached patch patch v1.3 (obsolete) — — Splinter Review
With this patch the charset observer can make the decision on whether to load a new charset or not.
With this patch the charset observer can make the decision on whether to load a new charset or not. This way other observers don't get affected.
Attachment #78984 - Attachment is obsolete: true
Comment on attachment 78986 [details] [diff] [review] patch v1.4 [ missed mozilla/intl/ in my previos patch ] sr=jst if you rename nsIHTMLDocument::IsWritten() to IsWriting(), and make the nsIElementObserver flag an enum in the nsIElementObserver interface in stead of a #define.
Attachment #78986 - Flags: superreview+
I ask hekki and harishd several time about putting adtxxx on status . due to lack of action, put the [adt1] here for now since it block 122507
Whiteboard: [adt1]
Attachment #72416 - Attachment is obsolete: true
Attachment #78976 - Attachment is obsolete: true
Attachment #78986 - Attachment is obsolete: true
Comment on attachment 79514 [details] [diff] [review] patch v1.5 [ includes jst's suggestions ] carrying over jst's sr= to the new patch that includes jst's suggestions
Attachment #79514 - Flags: superreview+
Whiteboard: [adt1] → [adt1][Need r= ]
Comment on attachment 79514 [details] [diff] [review] patch v1.5 [ includes jst's suggestions ] r=ftang
Attachment #79514 - Flags: review+
does the patch fix the problem reported in 125317, 125315 ? does the patch fix the following problem ? 1. open http://bugzilla.mozilla.org/attachment.cgi?id=70824&action=view 2. click any radio button 3. click button 4. a window will pop up. do you see blank in the window or some text. It show BLANK in the window without your fix. Does it still show blank after your patch ? or some text (or question mark) (even you may not be able to verify the text itself.)
Whiteboard: [adt1][Need r= ] → [adt1]
ftang: With my fix the popup has some text in it. That means the bug is fixed right?
Fix landed ( 04/18 ) on the trunk.
Whiteboard: [adt1] → [adt1][fixed on the trunk]
I try the patch on my Japanese nt, the patch does fix the problem in the origional report.
Keywords: adt1.0.0
I tested this with 2002-04-19 Win32 trunk, Linux trunk, and Mac trunk. Everything worked fine in trunk build.
adt1.0.0+ (on ADT's behalf) approval for checking into the 1.0 branch. Pls check this in today, then add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
Comment on attachment 79514 [details] [diff] [review] patch v1.5 [ includes jst's suggestions ] a=rjesup@wgate.com for branch checkin
Attachment #79514 - Flags: approval+
Fix landed ( 04/19 ) on the branch.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
Whiteboard: [adt1][fixed on the trunk] → [adt1][fixed on the trunk 04/18 and branch 04/19]
I verified this in 4-22-1.00 Win32, Mac, and Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: