Bug 171777 – Align our IDL files with the latest DOM specification

• Component: DOM
• Status: RESOLVED FIXED

[Chris Dumez]

Align our IDL files with the latest DOM specification:
- https://dom.spec.whatwg.org

[Chris Dumez]

Created attachment 309298 [details]
WIP Patch

[Chris Dumez]

Created attachment 309299 [details]
WIP Patch

[Chris Dumez]

Created attachment 309307 [details]
Patch

[Sam Weinig]

Comment on attachment 309307 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=309307&action=review

v.nice r=me

> Source/WebCore/dom/Document.idl:175
> +    // Non standard.
> +    Range caretRangeFromPoint(optional long x = 0, optional long y = 0);

I would note it has been superseded by caretPositionFromPoint, which we don't yet implement.

> Source/WebCore/dom/Range.idl:64
> +    DOMString toString(); // FIXME: Should be stringifier once we support it.

I believe we do support stringifier.  It's used in a number of other IDLs.

> Source/WebCore/dom/Range.idl:73
> +    // Non Standard API.

Might want to standardize on how you write "non standard".  In other places you left off the API and made standard all lowercase.

> Source/WebCore/dom/Text.idl:25
> +    [NewObject, MayThrowException] Text splitText(unsigned long offset);

What happens when offset is 0? Does it really still return a new object?

[Build Bot]

Comment on attachment 309307 [details]
Patch

Attachment 309307 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/3690427

New failing tests:
fast/dom/Range/split-text-in-range.html

[Build Bot]

Created attachment 309311 [details]
Archive of layout-test-results from ews114 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-elcapitan  Platform: Mac OS X 10.11.6

[Chris Dumez]

Comment on attachment 309307 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=309307&action=review

>> Source/WebCore/dom/Document.idl:175
>> +    Range caretRangeFromPoint(optional long x = 0, optional long y = 0);
> 
> I would note it has been superseded by caretPositionFromPoint, which we don't yet implement.

Ok. I wasn't aware. Thanks for the info. I'll add the note.

>> Source/WebCore/dom/Range.idl:64
>> +    DOMString toString(); // FIXME: Should be stringifier once we support it.
> 
> I believe we do support stringifier.  It's used in a number of other IDLs.

No. I added support a while back for stringifier, but only on attributes. We do not support yet:
stringifier;

>> Source/WebCore/dom/Range.idl:73
>> +    // Non Standard API.
> 
> Might want to standardize on how you write "non standard".  In other places you left off the API and made standard all lowercase.

Ok, will drop API.

>> Source/WebCore/dom/Text.idl:25
>> +    [NewObject, MayThrowException] Text splitText(unsigned long offset);
> 
> What happens when offset is 0? Does it really still return a new object?

Yes, we always return a new object, as per the spec:
- https://dom.spec.whatwg.org/#concept-text-split

That said, there is a test that is failing so I'll have to drop the NewObject anyway. The reason the test is failing is because we fire the DOMNodeInserted event synchronously before returning and therefore, the JS may have already created a wrapper for the Text node by the type we return, in the case where they have a DOMNodeInserted listener (see LayoutTests/fast/dom/Range/split-text-in-range.html).

[Chris Dumez]

Created attachment 309313 [details]
Patch

[Chris Dumez]

Created attachment 309314 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 309314 [details]
Patch

Clearing flags on attachment: 309314

Committed r216339: <http://trac.webkit.org/changeset/216339>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.