Bug 149370 – Get rid of most custom bindings for Location.idl

• Status: RESOLVED
• Resolution: FIXED
• Component: Bindings

[Chris Dumez]

Get rid of most custom bindings for Location.idl by extending the support for the [CallWith=XXX] IDL extended attribute.

[Chris Dumez]

Created attachment 261581 [details]
Patch

[Darin Adler]

Comment on attachment 261581 [details]
Patch

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

I think it’s strange that the extra arguments that give context to the setter come *before* the attribute value itself.

> Source/WebCore/bindings/js/JSDocumentCustom.cpp:68
> +// FIXME: Require support for [PutForward=XXX] Web IDL extended attribute.

I don’t think this is a very clear comment. I think what it means is that setting location isn’t correct until we add support for PutForward to the JavaScript bindings generator and then use it for the location attribute. But if that’s what it means, the wording is not really clear about that.

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:3180
> +    push(@callWithArgs, "exec") if $codeGenerator->ExtendedAttributeContains($callWith, "ScriptState");

Sure wish this would pass *exec instead of exec. We should start using the type ExecState& instead of ExecState* in new things we create.

[Chris Dumez]

Comment on attachment 261581 [details]
Patch

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

>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:3180
>> +    push(@callWithArgs, "exec") if $codeGenerator->ExtendedAttributeContains($callWith, "ScriptState");
> 
> Sure wish this would pass *exec instead of exec. We should start using the type ExecState& instead of ExecState* in new things we create.

Yes, I can do this in a follow-up.

[WebKit Commit Bot]

Comment on attachment 261581 [details]
Patch

Clearing flags on attachment: 261581

Committed r190017: <http://trac.webkit.org/changeset/190017>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Chris Dumez]

Follow-up GTK build fixes:
<https://trac.webkit.org/r190038>
<https://trac.webkit.org/r190039>