Bug 11633

Summary: Implement XMLDocument properties xmlEncoding, xmlVersion, xmlStandalone
Product: WebKit Reporter: Jesse Costello-Good <jesse>
Component: DOMAssignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, cdumez
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Bug Depends on:    
Bug Blocks: 10489    
Attachments:
Description Flags
proposed patch
sam: review-
proposed patch sam: review+

Jesse Costello-Good
Reported 2006-11-17 09:56:27 PST
For parity with Firefox: var req = new XMLHttpRequest(); req.open("GET", "test.xml", false); req.overrideMimeType("text/xml"); req.send(null); var doc = req.responseXML; assertEquals("utf-8", doc.xmlEncoding.toLowerCase()); assertEquals("1.0", doc.xmlVersion); assertEquals("yes", doc.xmlStandalone); Where test.xml is: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <data/> 
Attachments
proposed patch (23.99 KB, patch)
2006-11-19 14:53 PST, Alexey Proskuryakov 		sam: review-
DetailsFormatted DiffDiff
proposed patch (50.15 KB, patch)
2006-11-20 10:39 PST, Alexey Proskuryakov 		sam: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2006-11-17 10:28:59 PST
Once we get xmlEncoding, we should start using it in XMLHttpRequest ("If the data is a Document, it MUST be serialized using the encoding given by data.xmlEncoding, if specified and supported, or UTF-8 otherwise").
Jesse Costello-Good
Comment 2 2006-11-17 22:49:56 PST
XMLDocument.cloneNode() seems to always return null.
Alexey Proskuryakov
Comment 3 2006-11-17 23:36:28 PST
Could you please file a separate bug for cloneNode()? It isn't related to XML declaration properties, so it's unlikely that they will be implemented/fixed together.
Alexey Proskuryakov
Comment 4 2006-11-19 06:52:03 PST
Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=361198> for xmlEncoding behavior in Firefox, which seems wrong to me. XMLHttpRequest behavior isn't clear either - Firefox doesn't do what the spec says, and I'm not sure what we should do; asked on the webapi WG mailing list.
Alexey Proskuryakov
Comment 5 2006-11-19 14:53:02 PST
Created attachment 11576 [details] proposed patch The patch doesn't include changes to dom/xhtml/level3/core results - svn-create-patch chokes on these, probably because of the UTF-16 test that I re-added. One thing I don't like in this patch is that I had to add wk_ucfirst to both JS and ObjC generators - I couldn't make it work when it was in CodeGenerator.pm (calling it as $codeGenerator->wk_ucfirst resulted in something weird like "CodeGenerator->HASH(...) being printed to the output). Leaving this to someone more proficient with Perl for future cleanup.
Sam Weinig
Comment 6 2006-11-20 10:35:30 PST
Comment on attachment 11576 [details] proposed patch marking r- for reasons discussed in IRC.
Alexey Proskuryakov
Comment 7 2006-11-20 10:39:58 PST
Created attachment 11584 [details] proposed patch
Alexey Proskuryakov
Comment 8 2006-11-20 11:11:04 PST
Committed revision 17859.
Jesse Costello-Good
Comment 9 2006-11-28 10:12:37 PST
Thanks to the Safari team for being so responsive regarding requests for better advanced AJAX support. Safari is quickly becoming a 1st class AJAX platform.
Lucas Forschler
Comment 10 2019-02-06 09:03:16 PST
Mass moving XML DOM bugs to the "DOM" Component.
Note You need to log in before you can comment on or make changes to this bug.