Bug 15814

Summary: fast/js/kde/encode_decode_uri.html fails
Product: WebKit Reporter: Darin Adler <darin>
Component: JavaScriptCoreAssignee: Darin Adler <darin>
Status: RESOLVED FIXED    
Severity: Normal CC: ap
Priority: P2 Keywords: InRadar
Version: 523.x (Safari 3)   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
patch mjs: review+

Darin Adler
Reported 2007-11-03 00:44:32 PDT
The checked-in results include failures. Because of a failure in fast/js/resources/js-test-pre.js this test used to pass when it was really failing.
Attachments
patch (125.24 KB, patch)
2007-11-03 00:48 PDT, Darin Adler 		mjs: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Darin Adler
Comment 1 2007-11-03 00:48:36 PDT
Created attachment 17015 [details] patch
Darin Adler
Comment 2 2007-11-03 00:49:11 PDT
<rdar://problem/5536644>
Maciej Stachowiak
Comment 3 2007-11-03 01:36:25 PDT
Comment on attachment 17015 [details] patch r=me
Alexey Proskuryakov
Comment 4 2007-11-03 02:13:50 PDT
+ return throwError(exec, URIError); I think it would be good to add a string explaining the failure to throwError. - // Backwards BOM and U+FFFF should never appear in UTF-8 data. - if (c == 0xFFFE || c == 0xFFFF) - return -1; FWIW, Firefox gives different result for these character on this test: FAIL decodeURI(encodeURI(String.fromCharCode(65534))) should be &#65534;. Was &#65533;. FAIL decodeURI(encodeURI(String.fromCharCode(65535))) should be &#65535;. Was &#65533;.
Darin Adler
Comment 5 2007-11-03 09:42:27 PDT
(In reply to comment #4) > FAIL decodeURI(encodeURI(String.fromCharCode(65534))) should be &#65534;. Was > &#65533;. > FAIL decodeURI(encodeURI(String.fromCharCode(65535))) should be &#65535;. Was > &#65533;. This behavior seems a bit strange and it's not mentioned by the standard. What do you think we should do?
Darin Adler
Comment 6 2007-11-03 09:52:45 PDT
Committed revision 27406.
Alexey Proskuryakov
Comment 7 2007-11-04 02:44:16 PST
(In reply to comment #5) > This behavior seems a bit strange and it's not mentioned by the standard. What > do you think we should do? I think the new behavior is correct, although I do not know why a comment in the removed code said that "Backwards BOM and U+FFFF should never appear in UTF-8 data." Of course, those are non-characters, but there are 64 more of those, and according to the Unicode FAQ, UTF encoding should round-trip those.
Darin Adler
Comment 8 2007-11-04 16:31:21 PST
(In reply to comment #7) > I think the new behavior is correct, although I do not know why a comment in > the removed code said that "Backwards BOM and U+FFFF should never appear in > UTF-8 data." Of course, those are non-characters, but there are 64 more of > those, and according to the Unicode FAQ, UTF encoding should round-trip those. I wrote that comment. And I think I was wrong when I wrote it.
Note You need to log in before you can comment on or make changes to this bug.