Bug 153378 - An XMLDocument interface should be exposed on the global Window object
Summary: An XMLDocument interface should be exposed on the global Window object
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL: https://dom.spec.whatwg.org/#xmldocument
Keywords: InRadar, WebExposed
Depends on:
Blocks:
 
Reported: 2016-01-22 15:12 PST by Chris Dumez
Modified: 2016-01-24 17:11 PST (History)
5 users (show)

See Also:


Attachments
WIP Patch (59.48 KB, patch)
2016-01-22 21:15 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
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 Details
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 Details
Patch (62.94 KB, patch)
2016-01-23 16:09 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (62.96 KB, patch)
2016-01-24 16:20 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 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.
Comment 1 Chris Dumez 2016-01-22 21:15:07 PST
Created attachment 269638 [details]
WIP Patch
Comment 2 Build Bot 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
Comment 3 Build Bot 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
Comment 4 Build Bot 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
Comment 5 Build Bot 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
Comment 6 Alexey Proskuryakov 2016-01-23 12:35:32 PST
Previously WONTFIX'ed in bug 36465.
Comment 7 Ryosuke Niwa 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...
Comment 8 Chris Dumez 2016-01-23 16:09:00 PST
Created attachment 269678 [details]
Patch
Comment 10 Radar WebKit Bug Importer 2016-01-23 16:13:24 PST
<rdar://problem/24315465>
Comment 11 Chris Dumez 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.
Comment 12 Darin Adler 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);
Comment 13 Chris Dumez 2016-01-24 16:20:33 PST
Created attachment 269706 [details]
Patch
Comment 14 WebKit Commit Bot 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>
Comment 15 WebKit Commit Bot 2016-01-24 17:11:51 PST
All reviewed patches have been landed.  Closing bug.