KDE JS tests where Firefox disagrees

[Maks Orlovich]

On Tuesday 27 December 2005 22:00, Maciej Stachowiak wrote:
> I recently incorporated the KDE JS test suite into the WebKit layout
> tests. As part of the KJS/JSC merger work, we are trying to make
> JavaScriptCore pass all these.
>
> To double-check the tests, I tried them in Firefox and took a look at
> the spec where there was disagreement. Here are the discrepencies I
> found:
>
> parse.js
> ---------
> Firefox fails to parse this. So does Mac IE. What is the evidence
> that it should parse?

It parses when one supports Unicode identifiers. (I patched JSC to do so, and 
you have a different review+ (as of today) patch of your own that does that). 
Perhaps Mozilla doesn't support Unicode idents when they're not using \u1234? 
That would be kind of odd.


> exception_propagation.js
> -----------------------------
> fails to parse
> (MacIE parses it and gets up to checkOperator(">>>","OpURShift");,
> then bombs; needs further investigation)

The parse error is at the  throwex line in:
try {
  for (throwex() in forin_test_obj) {
    forin_count++;
  }
}
catch (e) {
}
shouldBe("forin_count","4");

No clue on what's appropriate here.


>
> evil-n.js
> ---------
> parses successfully, desipte the -n.js ending
> FAIL (new Error()).message should be undefined. Was
> (I think this test is just plain wrong and should be removed)

The changelog suggest this was some sort of an XFail-type hack. 
(May be it was done before we had proper XFail stuff? Dunno.)

>
> encode_decode_uri.js
> -------------------------
> FAIL checkWithFunctions(encodeURI,decodeURI) should be true. Was false
> FAIL checkWithFunctions(encodeURIComponent,decodeURIComponent) should
> be true. Was false
> (is this test case actually correct? can't tell - it also fails in
> Mac IE)

Please see the attached diff to make the test more explicit. 
Basically, it detects two things in JSC:
1. JSC doesn't throw errors when given invalid sequences to 
encode (basically, broken pieces of surrogate pairs). That's mandated by the 
spec, and all other browsers I tested ---- WinIE, Firefox, Konq and Opera ---
throw the error. One way of fixing it is something like this:

 static ValueImp *encode(ExecState *exec, const List &args, const char 
*do_not_escape)
 {
   UString r = "", s, str = args[0]->toString(exec);
+
+  //Check to make sure that surrogate pair chars are used in a 
+  //well-formed fashion (15.1.3, steps 9 and 14)
+  for (int k = 0; k < str.size(); ++k) {
+    unsigned short code = str[k].unicode();
+    if (code >= 0xDC00 && code <= 0xDFFF)
+        return throwError(exec, URIError);
+    if (code >= 0xD800 && code <= 0xDBFF) {
+        //Surrogate pair, check 2nd 
+        if (k + 1 >= str.size() || 
+            !(str[k + 1].unicode() >= 0xDC00 && str[k + 1].unicode() <= 
0xDFFF))
+            return throwError(exec, URIError);
+
+        ++k; //Skip 2nd part of pair.
+    }
+  }
+
   CString cstr = str.UTF8String();
   const char *p = cstr.c_str();
   for (int k = 0; k < cstr.size(); k++, p++) {

2. JSC doesn't like converting 0xFFFE back from Unicode. That's sort of 
excusable (it's kind of an invalid value). Mozilla substitutes in 0xFFFD 
('Replacement char') when decoding.  WinIE and Opera (and Konq 3.5, 
obviously) just take it. I think this one can be viewed either way. 


On the flip side, I believe the following test is wrong:
FAIL. var reg = /ab/g; 'aabab'.match(reg); reg.lastIndex should be 0. Was 3
15.5.4.10 says lastIndex should be set in global case. Or does anyone know any 
good reason to follow mozilla and not the spec here? (WinIE returns 5 here.)


-Maks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: moreinfo.diff
Type: text/x-diff
Size: 3661 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20051230/d1b5fb5c/attachment.diff>