WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
11633
Implement XMLDocument properties xmlEncoding, xmlVersion, xmlStandalone
https://bugs.webkit.org/show_bug.cgi?id=11633
Summary
Implement XMLDocument properties xmlEncoding, xmlVersion, xmlStandalone
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-
Details
Formatted Diff
Diff
proposed patch
(50.15 KB, patch)
2006-11-20 10:39 PST
,
Alexey Proskuryakov
sam
: review+
Details
Formatted Diff
Diff
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.
Top of Page
Format For Printing
XML
Clone This Bug