Bug 153378

Summary: An XMLDocument interface should be exposed on the global Window object
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: DOMAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, buildbot, commit-queue, rniwa, webkit-bug-importer
Priority: P2 Keywords: InRadar, WebExposed
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
URL: https://dom.spec.whatwg.org/#xmldocument
Attachments:
Description Flags
WIP Patch
none
Archive of layout-test-results from ews101 for mac-yosemite
none
Archive of layout-test-results from ews114 for mac-yosemite
none
Patch
none
Patch none

Chris Dumez
Reported 2016-01-22 15:12:58 PST
An XMLDocument interface needs to be exposed on the global Window object, as per: https://dom.spec.whatwg.org/#xmldocument Currently, WebKit aliases XMLDocument to Document which causes some W3C tests to fail. Chrome and Firefox already match the specification here.
Attachments
WIP Patch (59.48 KB, patch)
2016-01-22 21:15 PST, Chris Dumez
no flags
Archive of layout-test-results from ews101 for mac-yosemite (766.79 KB, application/zip)
2016-01-22 22:15 PST, Build Bot
no flags
Archive of layout-test-results from ews114 for mac-yosemite (849.36 KB, application/zip)
2016-01-22 22:22 PST, Build Bot
no flags
Patch (62.94 KB, patch)
2016-01-23 16:09 PST, Chris Dumez
no flags
Patch (62.96 KB, patch)
2016-01-24 16:20 PST, Chris Dumez
no flags
Chris Dumez
Comment 1 2016-01-22 21:15:07 PST
Created attachment 269638 [details] WIP Patch
Build Bot
Comment 2 2016-01-22 22:15:55 PST
Comment on attachment 269638 [details] WIP Patch Attachment 269638 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/728068 New failing tests: http/tests/security/cross-frame-access-put.html svg/custom/manually-parsed-embedded-svg-allowed-in-dashboard.html http/tests/xmlhttprequest/svg-created-by-xhr-allowed-in-dashboard.html
Build Bot
Comment 3 2016-01-22 22:15:59 PST
Created attachment 269653 [details] Archive of layout-test-results from ews101 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-yosemite Platform: Mac OS X 10.10.5
Build Bot
Comment 4 2016-01-22 22:22:45 PST
Comment on attachment 269638 [details] WIP Patch Attachment 269638 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/728053 New failing tests: http/tests/security/cross-frame-access-put.html svg/custom/manually-parsed-embedded-svg-allowed-in-dashboard.html http/tests/xmlhttprequest/svg-created-by-xhr-allowed-in-dashboard.html
Build Bot
Comment 5 2016-01-22 22:22:49 PST
Created attachment 269654 [details] Archive of layout-test-results from ews114 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
Alexey Proskuryakov
Comment 6 2016-01-23 12:35:32 PST
Previously WONTFIX'ed in bug 36465.
Ryosuke Niwa
Comment 7 2016-01-23 15:33:27 PST
(In reply to comment #6) > Previously WONTFIX'ed in bug 36465. DOM spec now defines XMLDocument: https://dom.spec.whatwg.org/#xmldocument I don't quite understand the purpose of it though...
Chris Dumez
Comment 8 2016-01-23 16:09:00 PST
Radar WebKit Bug Importer
Comment 10 2016-01-23 16:13:24 PST
Chris Dumez
Comment 11 2016-01-23 16:30:21 PST
(In reply to comment #7) > (In reply to comment #6) > > Previously WONTFIX'ed in bug 36465. > > DOM spec now defines XMLDocument: https://dom.spec.whatwg.org/#xmldocument > > I don't quite understand the purpose of it though... It seems part of the reason why XMLDocument exists is to expose load() to XMLDocuments (but not HTML ones): https://html.spec.whatwg.org/#dom-xmldocument-load We don't seem to implement Document.load() at the moment. That said, other browsers have XMLDocument, it is in the HTML / DOM specs, it is covered by standards compliance tests, and it is not much effort or code to support it.
Darin Adler
Comment 12 2016-01-24 12:18:59 PST
Comment on attachment 269678 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=269678&action=review > Source/WebCore/dom/DOMImplementation.idl:40 > + [ObjCLegacyUnnamedParameters, RaisesException] Document createDocument([TreatNullAs=NullString, TreatUndefinedAs=NullString, Default=Undefined] optional DOMString namespaceURI, > + [TreatNullAs=NullString, Default=Undefined] optional DOMString qualifiedName, > + [TreatNullAs=NullString, Default=Undefined] optional DocumentType doctype); So wordy, and yet many these properties like TreatNullAs and Default aren’t even used by ObjC and GObject bindings. > Source/WebCore/dom/DOMImplementation.idl:44 > + [RaisesException, NewObject] XMLDocument createDocument([TreatNullAs=NullString, TreatUndefinedAs=NullString, Default=Undefined] optional DOMString namespaceURI, > [TreatNullAs=NullString, Default=Undefined] optional DOMString qualifiedName, > [TreatNullAs=NullString, Default=Undefined] optional DocumentType doctype); Indentation seems random. > Source/WebCore/dom/XMLDocument.h:48 > + XMLDocument(Frame* frame, const URL& url, unsigned documentClasses) > + : Document(frame, url, documentClasses) > + { } Seems like this constructor should either do: : Document(frame, url, XMLDocumentClass | documentClasses) or: ASSERT(documentClasses & XMLDocumentClass);
Chris Dumez
Comment 13 2016-01-24 16:20:33 PST
WebKit Commit Bot
Comment 14 2016-01-24 17:11:45 PST
Comment on attachment 269706 [details] Patch Clearing flags on attachment: 269706 Committed r195520: <http://trac.webkit.org/changeset/195520>
WebKit Commit Bot
Comment 15 2016-01-24 17:11:51 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.