Closed Bug 13524 Opened 25 years ago Closed 25 years ago

[BETA] JS string object function does not work on Non-Ascii strings

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: teruko, Assigned: vidur)

References

(
URL
)

Details

Above URL has String Object, CharAt(), indexOf(), lastIndexOf(), substring(), toLowerCase(), toUpperCase() for Latin2 and Japanese Shift_jis and Euc test cases. None of the test cases works. Steps of reproduce 1. Go to the URL 2. Click on string_latin2.html 3. Click on string_sjis.html 4. Click on string_euc.html Every test cases does not work. Tested 9-09-99 Win32 build.
Priority: P3 → P2
QA Contact: cbegle → teruko
Summary: JS string object function does not work on No Ascii strings → JS string object function does not work on Non-Ascii strings
Assignee: mccabe → rogerl
Roger, can you find a home for this? It's possible that the problem isn't with the functions, but with the document encoding.
Status: NEW → ASSIGNED
Yurk! I need help with this - when I look at the html it's just a bunch of statements that display pass/fail - how do I get a look at the actual JS code?
To look at the source code of string_sjis.html file, view-source: http://babel/javascript_i18n/string/string_sjis.html or from the Network neigborhood \\babel\babel_docs\javascript_i18n\string\string_sjis.html
Assignee: rogerl → troy
Status: ASSIGNED → NEW
Component: Javascript Engine → Layout
This is not a JS engine bug. All of the string routines are being called with the correct parameters and are returning the right results. Those results are not being displayed correctly - because of various tags in the HTML. I don't know nearly enough about HTML to say whether this should work or not. Except of course that it runs find under 4.6 etc. I trimmed the HTML down and ended up with this piece which displays just fine under 4.6 but not with the current build (umm, three days old). It's possible that there are other bugs i trimmed in the process. <HTML> <BODY> <SCRIPT> document.write("<PRE>"); document.write("More Stuff".bold(), "\n"); document.write("here's that stuff"); document.write("</PRE>"); </SCRIPT> </BODY> </HTML> Note that when the line 'document.write("</PRE>");' is commented out, things work ok. (Well, spot the weird 'Q' after the bolded text)
Assignee: troy → vidur
Known issue of document.write not working. I don't know if this is you or Peter
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
The document.write bug is 11141. *** This bug has been marked as a duplicate of 11141 ***
Status: RESOLVED → REOPENED
I tested this in 120108 build. Bug 11141 has been fixed, but this still failed. I need to reopen this.
Resolution: DUPLICATE → ---
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
String_sjis.html passed, but some garbage characters are displayed. String_euc.html and String_latin2.html do not pass and garbage characters are displayed. String_latin1.html does not pass in Communicator 4.7, either. I will check the test case.
Assignee: vidur → ftang
Status: ASSIGNED → NEW
I fixed a simple bug that was causing us to add extra characters to the end of document.writes of unicode characters (patch attached). However, there's still another bug that causes non-deterministic failures in the tests. I've seen the tests fail or the scripts themselves not compile because of missing characters in the SCRIPT element content. After looking at it for quite a while, I believe that the character dropping is happening in the character buffer to unicode conversion driven from the scanner. I believe the errant code is somewhere in nsUnicodeDecodeHelper. Passing the bug on to ftang for further investigation. The patch for the bug that I fixed in the HTMLContentSink is: Index: nsHTMLDocument.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/document/src/nsHTMLDocument.cpp,v retrieving revision 3.177 diff -c -r3.177 nsHTMLDocument.cpp *** nsHTMLDocument.cpp 1999/12/09 07:18:38 3.177 --- nsHTMLDocument.cpp 1999/12/11 01:49:50 *************** *** 1835,1841 **** JSString *jsstring = JS_ValueToString(cx, argv[index]); if (nsnull != jsstring) { ! str.Append(JS_GetStringChars(jsstring)); } } --- 1835,1841 ---- JSString *jsstring = JS_ValueToString(cx, argv[index]); if (nsnull != jsstring) { ! str.Append(JS_GetStringChars(jsstring), JS_GetStringLength(jsstring)); } }
I'll try to get the patch in for M12. If not, then M13. Frank, feel free to apply it to your tree if you don't want to see the extra characters.
Status: NEW → ASSIGNED
Assignee: ftang → bobj
Status: ASSIGNED → NEW
bob, I can use some help here.
Status: NEW → ASSIGNED
Teruko, I assume this is not a dogfood candidate? But it should be fixed for Beta, right?
Summary: JS string object function does not work on Non-Ascii strings → [BETA] JS string object function does not work on Non-Ascii strings
Added [BETA] in summary.
Blocks: 22176
Target Milestone: M13
Vidur, Will you be able to apply your patch in M13?
I saw rev-3.119 contains the fix mentioned here. So it's ready in.
Assignee: bobj → vidur
Status: ASSIGNED → NEW
vidur, You checked in your patch for Version 3.180. I'm reassigning it to you and then will mark it FIXED. Please modify this bug if this is not the correct thing to do. Thx.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
The suggested patch was already applied. See previous comment.
Status: RESOLVED → VERIFIED
I verified this in 111008 Win32, 111208 Linux build. I see some display problem in Latin2 page. I will investigate more the problem and I will log in new bug.
No longer blocks: 22176
You need to log in before you can comment on or make changes to this bug.