Closed Bug 12889 Opened 20 years ago Closed 20 years ago

XUL widgets fail to display with charsets ks_c_5601-1987...

Categories

(Core :: Internationalization, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: amasri, Assigned: ftang)

References

()

Details

with WinNT, apprunner 19990827; with MacOS 8.5,apprunner 199082712

Steps to reproduce:
1. launch apprunner
2. open http://babel/automation/erik/framework/
3. select link "Display xml widgets"
4. select any of these charsets:
     ks_c_5601-1987/ko
     ksc5601/ko
     x-x-big5/zh-TW

Result: apprunner returns a server error.

Regression: this does not happen with any of the other fonts, nor with
fonts/styles tests, which use similar perl script (see widgets.pl in same
directory for script)
Depends on: 12394
QA Contact: teruko → amasri
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
There ARE a server error as report by the HTTP server. This is not a bug in
SeaMonkey, this is a bug in the test script of the CGI. Invalid bug
Status: RESOLVED → REOPENED
Yes, the server error is real--but the cgi test script is identical for each
case, except for the charset and the test characters. It must be identical,
because these two are the only parameters to the cgi function,
right_frame() (widgets.pl, l. 52). Since these are the only
differences, and since the cgi test works in all other cases, it follows that
either the charset or the test characters must cause the server error. To prove
this, just select any of the other charsets on the widgets page.

I'm attaching the source for the cgi.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Frank is correct--problem lies in framework, not in cgi script itself. The
charsets in question do not have "ushort" files (unicode).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.