Changes between Version 51 and Version 52 of WebKitIDL
- Timestamp:
- Feb 20, 2012, 5:10:46 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WebKitIDL
v51 v52 278 278 279 279 Usage: The possible usage is [TreatReturnedNullStringAs=Null], [TreatReturnedNullStringAs=Undefined] or [TreatReturnedNullStringAs=False]. 280 They can be specified on DOMString attributes or methods whichreturn a DOMString value:280 They can be specified on DOMString attributes or methods that return a DOMString value: 281 281 {{{ 282 282 attribute [TreatReturnedNullStringAs=Null] DOMString str; … … 558 558 Summary: ADD SUMMARY 559 559 560 Usage: [Reflect] can be specified on attributes .560 Usage: [Reflect] can be specified on attributes: 561 561 {{{ 562 562 attribute [Reflect] DOMString str; … … 727 727 * [http://old.nabble.com/Things-missing-from-Web-IDL-for-HTML5-td24873773.html Easy explanation of Supplemental] 728 728 729 Summary: [Supplemental] helps WebKit modularization. [Supplemental] makes it possible to add XXX's APIs (e.g. XXX=WebAudio, WebSocket, Blob, GamePad, ...etc) without modifying code outside of WebCore/Modules/XXX/. This helps make XXX a "self-contained module". 729 Summary: [Supplemental] helps WebKit modularization. 730 [Supplemental] makes it possible to add XXX's APIs (e.g. XXX=WebAudio, WebSocket, Blob, GamePad, ...etc) without modifying code outside of WebCore/Modules/XXX/. 731 This helps make XXX a "self-contained module". 730 732 731 733 Usage: The possible usage is … … 736 738 }; 737 739 }}} 738 where XXX implements YYY. [Supplemental] can be specified on interfaces. 739 740 Here is an example. Without [Supplemental], if you want to add XXX's attributes or methods to DOMWindow, 740 where XXX implements YYY. 741 [Supplemental] can be specified on interfaces. 742 743 Without [Supplemental], if you want to add XXX's attributes or methods to DOMWindow, 741 744 742 745 * you need to modify WebCore/page/DOMWindow.idl to add the XXX's attributes or methods 743 746 744 * you need to modify WebCore/page/DOMWindow.{h,cpp} to add the C++implementation of the attribute getters and setters or the method callbacks.747 * you need to modify WebCore/page/DOMWindow.{h,cpp} to add the WebCore implementation of the attribute getters and setters or the method callbacks. 745 748 746 749 On the other hand, in the modularized world with [Supplemental], you just need to modify the code under WebCore/Modules/XXX/: … … 753 756 Supplemental=DOMWindow // The attributes and methods of this interface are exposed as those of DOMWindow. 754 757 ] DOMWindowXXX { 755 attribute foo;758 attribute int foo; 756 759 void bar(); 757 760 }; … … 761 764 762 765 {{{ 763 DOMWindowXXX::foo(...) { ... } // The C++ implementation of the foo attribute getter. 764 DOMWindowXXX::setFoo(...) { ... } // The C++ implementation of the foo attribute setter. 765 DOMWindowXXX::bar(...) { ... } // The C++ implementation of the bar method callback. 766 }}} 767 768 As shown above, [Supplemental=DOMWindow] indicates that all the attributes and methods of DOMWindowXXX should be exposed on DOMWindow, but should be implemented in DOMWindowXXX. In this way, you can implement the attributes and methods without modifying code of DOMWindow.{h,cpp,idl}. 769 770 If you want to add APIs whose implementations are likely to be independent from WebCore, it is strongly recommended to put the APIs and .h/.cpp files into WebCore/Modules/XXX/ using [Supplemental]. 771 772 == [Constructor](i), [CallWith](i,m,a), [ConstructorRaisesException](i) == #Constructor 766 DOMWindowXXX::foo(...) { ... } // The WebCore implementation of the foo attribute getter. 767 DOMWindowXXX::setFoo(...) { ... } // The WebCore implementation of the foo attribute setter. 768 DOMWindowXXX::bar(...) { ... } // The WebCore implementation of the bar() method callback. 769 }}} 770 771 As shown above, [Supplemental=DOMWindow] indicates that all the attributes and methods of DOMWindowXXX should be exposed on DOMWindow, 772 but should be implemented in DOMWindowXXX. 773 In this way, you can implement the attributes and methods without modifying code of DOMWindow.{h,cpp,idl}. 774 775 If you want to add APIs whose implementations are likely to be independent from WebCore, 776 it is strongly recommended to put the APIs and .h/.cpp files into WebCore/Modules/XXX/ using [Supplemental]. 777 On the other hand, if the implementations need to touch WebCore much, 778 the APIs might not be good candidates for [Supplemental]. 779 780 == [Constructor](i), [CallWith](i,m,a), [ConstructorRaisesException](i) == #Constructor 773 781 774 782 * [http://dev.w3.org/2006/webapi/WebIDL/#Constructor The spec of Constructor] 775 783 776 Summary: It indicates that the interface should have constructor "new XXX()". 784 Summary: [Constructor] indicates that the interface should have constructor, i.e. "new XXX()". 785 [CallWith] and [ConstructorRaisesException] adds information when the constructor callback is called in WebCore. 777 786 778 787 Usage: [Constructor], [CallWith] and [ConstructorRaisesException] can be specified on interfaces: … … 786 795 }}} 787 796 788 [Constructor(in float x, in float y, in DOMString str)] means that the interface has constructor797 [Constructor(in float x, in float y, in DOMString str)] means that the interface has a constructor 789 798 and the constructor signature is (in float x, in float y, in DOMString str). 790 Specifically, JavaScript can generate a DOM object of XXX by the following code:799 Specifically, JavaScript can create a DOM object of XXX by the following code: 791 800 {{{ 792 801 var x = new XXX(1.0, 2.0, "hello"); 793 802 }}} 794 803 Then XXX::create(float x, float y, String str) is called in WebCore. 795 Specifically, WebCore needs to implement the following method:804 That way WebCore needs to implement the following method as a constructor callback: 796 805 {{{ 797 806 PassRefPtr<XXX> XXX::create(float x, float y, String str) … … 803 812 [Constructor()] is equivalent to [Constructor]. 804 813 805 If the WebCore methodcan throw Exception, you can use [ConstructorRaisesException].806 With [ConstructorRaisesException], a n ExceptionCode argumentis added to the tail argument of XXX::create(...).814 If XXX::create(...) can throw Exception, you can use [ConstructorRaisesException]. 815 With [ConstructorRaisesException], a placeholder for ExceptionCode is added to the tail argument of XXX::create(...). 807 816 {{{ 808 817 PassRefPtr<XXX> XXX::create(float x, float y, String str, ExceptionCode& ec) … … 816 825 }}} 817 826 818 If the WebCore methodneeds additional information like ScriptExecutionContext and ScriptState,819 you can specify it by[CallWith=ScriptExecutionContext|ScriptState].820 Then the WebCore methodcan have the following signature:827 If XXX::create(...) needs additional information like ScriptExecutionContext and ScriptState, 828 you can specify [CallWith=ScriptExecutionContext|ScriptState]. 829 Then XXX::create(...) can have the following signature: 821 830 {{{ 822 831 PassRefPtr<XXX> XXX::create(ScriptExecutionContext* context, ScriptState* state, float x, float y, String str) … … 826 835 }}} 827 836 You can retrieve document or frame from ScriptExecutionContext. 828 Please see another [CallWith] sectionfor more details.829 830 Note that [CallWith=...] arguments are added at the head of the WebCore methodarguments,831 and the ExceptionCode argument is added at the tail of the WebCore methodarguments.837 Please see [#CallWith another [CallWith] section] for more details. 838 839 Note that [CallWith=...] arguments are added at the head of XXX::create(...)'s arguments, 840 and the ExceptionCode argument is added at the tail of XXX::create(...)'s arguments. 832 841 833 842 Whether you should allow an interface to have constructor depends on the spec of the interface. 834 843 835 == 844 == [ConstructorTemplate](i), [InitializedByEventConstructor](a) == #ConstructorTemplate 836 845 837 846 Summary: They are used for Event constructors. 838 847 839 848 Usage: The possible usage is [ConstructorTemplate=Event]. 840 [ConstructorTemplate=Event] can be specified on Event interfaces .849 [ConstructorTemplate=Event] can be specified on Event interfaces only. 841 850 [InitializedByEventConstructor] can be specified on attributes in the Event interfaces: 842 851 {{{ … … 849 858 }}} 850 859 851 Since constructors for Event interfaces require special binding ,860 Since constructors for Event interfaces require special bindings, 852 861 you need to use [ConstructorTemplate=Event] instead of normal [Constructor]. 853 862 854 863 If you specify [ConstructorTemplate=Event] on FooEvent, 855 JavaScript can make a DOM object of FooEvent in the following code:864 JavaScript can create a DOM object of FooEvent in the following code: 856 865 {{{ 857 866 var e = new FooEvent("type", { bubbles: true, cancelable: true }); 858 867 }}} 859 868 Then FooEvent::create(...) is called in WebCore. 860 Specifically, WebCore needs to implement the following method :861 {{{ 862 PassRefPtr<FooEvent> FooEvent::create(const AtomicString& type, const ProgressEventInit& initializer)869 Specifically, WebCore needs to implement the following method as a constructor callback: 870 {{{ 871 PassRefPtr<FooEvent> FooEvent::create(const AtomicString& type, const FooEventInit& initializer) 863 872 { 864 873 ...; … … 867 876 868 877 [InitializedByEventConstructor] should be specified on all the attributes 869 whichneeds to be initialized by the constructor.870 Which attributes need s initialization is defined in the spec.878 that needs to be initialized by the constructor. 879 Which attributes need initialization is defined in the spec of each Event interface. 871 880 For example, look at [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#event the spec of Event]. 872 EventInit dictionary has bubbles and cancelable, and thus bubbles and cancelable are the only attributes873 that need sto be initialized by the Event constructor.881 The EventInit dictionary has bubbles and cancelable, and thus bubbles and cancelable are the only attributes 882 that need to be initialized by the Event constructor. 874 883 In other words, in case of Event, you should specify [InitializedByEventConstructor] on bubbles and cancelable. 875 884 … … 878 887 * [http://dev.w3.org/2006/webapi/WebIDL/#NamedConstructor The spec of NamedConstructor] 879 888 880 Summary: If the interface name XXX and "new YYY()" name are different (i.e. XXX != YYY), you can use [NamedConstructor]. 881 882 Usage: The possible usage of [NamedConstructor] is [NamedConstructor=YYY]. 889 Summary: If you want to allow JavaScript to create a DOM object of XXX using a different name constructor 890 (i.e. allow JavaScript to create an XXX object using "new YYY()", where YYY != XXX), you can use [NamedConstructor]. 891 892 Usage: The possible usage is [NamedConstructor=YYY]. 883 893 [NamedConstructor] can be specified on interfaces: 884 894 {{{ … … 889 899 }}} 890 900 891 The semantics is the same as [Constructor], except that JavaScript can make a DOM object not by "new HTMLAudioElement( ...)" but by "Audio()".892 893 Whether you should allow an interface to have a named constructor depends on the spec of theinterface.901 The semantics is the same as [Constructor], except that JavaScript can make a DOM object not by "new HTMLAudioElement()" but by "Audio()". 902 903 Whether you should allow an interface to have a named constructor or not depends on the spec of each interface. 894 904 895 905 == [CustomConstructor](i), [JSCustomConstructor](i), [V8CustomConstructor](i), [ConstructorParameters](i) == #CustomConstructor … … 897 907 Summary: They allow you to write custom bindings for constructors. 898 908 899 Usage: They can specified on interfaces.909 Usage: They can be specified on interfaces. 900 910 Regarding [ConstructorParameters], the possible usage is [ConstructorParameters=X], where X is the maximum number of arguments of the constructor: 901 911 {{{ 902 912 interface [ 903 913 CustomConstructor, 904 Constr actorParameters=4914 ConstructorParameters=4 905 915 ] XXX { 906 916 }; … … 913 923 Before explaining the details, let us clarify the relationship of these IDL attributes. 914 924 915 * [JSCustomConstructor] on an interface indicates that you want towrite JavaScriptCore custom bindings for the constructor.916 * [V8CustomConstructor] on an interface indicates that you want towrite V8 custom bindings for the constructor.925 * [JSCustomConstructor] on an interface indicates that you can write JavaScriptCore custom bindings for the constructor. 926 * [V8CustomConstructor] on an interface indicates that you can write V8 custom bindings for the constructor. 917 927 * [CustomConstructor] is equivalent to [JSCustomConstructor, V8CustomConstructor]. 918 928 … … 920 930 then the constructor is generated only for V8 and you need to write JavaScriptCore custom bindings for the constructor. 921 931 922 How to write custom bindings aredifferent between JavaScriptCore and V8.932 How to write custom bindings is different between JavaScriptCore and V8. 923 933 924 934 * JavaScriptCore: Consider the following example: … … 931 941 }; 932 942 }}} 933 You need to prepare WebCore/bindings/js/JSXXXCustom.cpp and write custom bindings:934 {{{ 935 EncodedJSValue JSC_HOST_CALL JSXXXConstructor::constructJS SharedWorker(ExecState* exec)943 Then you can write custom bindings in WebCore/bindings/js/JSXXXCustom.cpp: 944 {{{ 945 EncodedJSValue JSC_HOST_CALL JSXXXConstructor::constructJSXXX(ExecState* exec) 936 946 { 937 947 ...; … … 949 959 }; 950 960 }}} 951 You need to prepare WebCore/bindings/v8/custom/V8XXXConstructor.cpp and write custom bindings:961 Then you can write custom bindings in WebCore/bindings/v8/custom/V8XXXConstructorCustom.cpp: 952 962 {{{ 953 963 v8::Handle<v8::Value> V8XXX::constructorCallback(const v8::Arguments& args) … … 956 966 } 957 967 }}} 958 Refer to WebCore/bindings/v8/custom/V8XXXConstructor .cpp for more details.968 Refer to WebCore/bindings/v8/custom/V8XXXConstructorCustom.cpp for more details. 959 969 960 970 X of [ConstructorParameters=X] is the maximum number of arguments, including optional arguments. 961 For example, if the constructor signature is [Constructor(in int a, in int b, in [Optional] int c, in [Optional] int d)], then X is 4. 971 For example, if a constructor signature is [Constructor(in int a, in int b, in [Optional] int c, in [Optional] int d)], then X is 4. 972 962 973 You do not need to specify [ConstructorParameters] if the interface does not have any of [JSCustomConstructor], [V8CustomConstructor] or [CustomConstructor]. 963 974 964 == 965 966 Summary: Itinserts "#if ENABLE(SOME_FLAG) ... #endif" into the generated code.975 == [Conditional](i,m,a) == #Conditional 976 977 Summary: [Conditional] inserts "#if ENABLE(SOME_FLAG) ... #endif" into the generated code. 967 978 968 979 Usage: [Conditional] can be specified on interfaces, methods and attributes: … … 980 991 }}} 981 992 982 [Conditional] is used to enable /disable the generated code based on the flag.983 If theflag is enabled, the generated code is compiled. Otherwise, the generated code is not compiled.984 Whether a flag is enabled or disabled is controlled by Tools/Scripts/build-webkit.985 986 If [Conditional] is specified on an interface, it means that [Conditional] is specified on all attributes and methods o nthe interface.993 [Conditional] is used to enable or disable the generated code based on a "flag". 994 If a given flag is enabled, the generated code is compiled. Otherwise, the generated code is not compiled. 995 Whether a flag is enabled or disabled is controlled (mostly) by Tools/Scripts/build-webkit. 996 997 If [Conditional] is specified on an interface, it means that [Conditional] is specified on all attributes and methods of the interface. 987 998 988 999 == [V8EnabledAtRuntime](i,m,a) == #V8EnabledAtRuntime 989 1000 990 Summary: In Chromium/V8, you can enable /disable a flag at runtime.1001 Summary: In Chromium/V8, you can enable or disable a flag at runtime. 991 1002 992 1003 Usage: The possible usage is [V8EnabledAtRuntime] or [V8EnabledAtRuntime=X], 993 where X is an arbitrary string whichyou want to use for identifying the flag getter.994 [V8EnabledAtRuntime] can be specified on interfaces, methods andattributes:1004 where X is an arbitrary string that you want to use for identifying the flag getter. 1005 [V8EnabledAtRuntime] can be specified on interfaces, methods or attributes: 995 1006 {{{ 996 1007 interface [ … … 1008 1019 }}} 1009 1020 1010 In Chromium/V8, you can enable/disable flags in the about:flags page. 1011 To make interfaces/methods/attributes controllable through about:flags, you can specify [V8EnabledAtRuntime]. 1012 1013 If [V8EnabledAtRuntime] is specified on an interface, 1014 it means that [V8EnabledAtRuntime] is specified on all attributes and methods on the interface....; 1015 1016 If you add [V8EnabledAtRuntime], you need to write "flag-binding" code 1021 To make interfaces, methods or attributes enabled or disabled through the about:flags page of Chromium/V8, you can specify [V8EnabledAtRuntime]. 1022 1023 If you specify [V8EnabledAtRuntime], you need to write "flag-binding" code 1017 1024 in WebCore/bindings/generic/RuntimeEnabledFeatures.h, WebCore/bindings/generic/RuntimeEnabledFeatures.cpp 1018 1025 and WebKit/chromium/src/WebRuntimeFeatures.cpp. 1019 1026 1020 The method name of a flag getterin WebCore/bindings/generic/RuntimeEnabledFeatures.h1021 is determined by the name of interfaces/methods/attributes.1022 You can change the method name by using [V8EnabledAtRuntime=X].1027 The method names of a "flag-binding" code in WebCore/bindings/generic/RuntimeEnabledFeatures.h 1028 are determined by the name of interfaces, methods or attributes by default. 1029 You can change the method names by using [V8EnabledAtRuntime=X], where X becomes the method name base. 1023 1030 Refer to WebCore/bindings/generic/RuntimeEnabledFeatures.h, WebCore/bindings/generic/RuntimeEnabledFeatures.cpp 1024 1031 and WebKit/chromium/src/WebRuntimeFeatures.cpp for more details. 1025 1032 1033 If [V8EnabledAtRuntime] is specified on an interface, 1034 it means that [V8EnabledAtRuntime] is specified on all the attributes and methods of the interface, 1035 1026 1036 == [CustomToJSObject](i), [JSCustomToJSObject](i), [V8CustomToJSObject](i) == #CustomToJSObject 1027 1037 … … 1036 1046 }}} 1037 1047 1038 * [JSCustomToJSObject] on an interface indicates that you want towrite custom toJS().1039 * [V8CustomToJSObject] on an interface indicates that you want towrite custom toV8().1048 * [JSCustomToJSObject] on an interface indicates that you can write custom toJS(). 1049 * [V8CustomToJSObject] on an interface indicates that you can write custom toV8(). 1040 1050 * [CustomToJSObject] is equivalent to [JSCustomToJSObject, V8CustomToJSObject]. 1041 1051 1042 By default, toJS() and toV8() are automatically generated in JSXXX.h and JSXXX.cpp or V8XXX.h and V8XXX.cpp. 1043 With [CustomToJSObject] or [JSCustomToJSObject], you can write custom toJS() WebCore/bindings/js/JSXXXCustom.cpp: 1052 By default (i.e. without [*CustomToJSObject]), toJS() and toV8() are generated automatically. 1053 1054 * With [CustomToJSObject] or [JSCustomToJSObject], you can write custom toJS() in WebCore/bindings/js/JSXXXCustom.cpp: 1055 1044 1056 {{{ 1045 1057 JSValue toJS(ExecState* exec, JSDOMGlobalObject* globalObject, XXX* impl) … … 1048 1060 } 1049 1061 }}} 1050 With [CustomToJSObject] or [V8CustomToJSObject], you can write custom toV8() WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1062 * With [CustomToJSObject] or [V8CustomToJSObject], you can write custom toV8() in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1063 1051 1064 {{{ 1052 1065 v8::Handle<v8::Value> toV8(XXX* impl, bool forceNewObject) … … 1056 1069 }}} 1057 1070 1058 == 1059 1060 Summary: It checks if a given Frame access is allowed or not, in terms of security.1071 == [CheckSecurity](i), [DoNotCheckSecurity](m,a), [DoNotCheckSecurityOnGetter](a), [DoNotCheckSecurityOnSetter](a) == #CheckSecurity 1072 1073 Summary: They check whether a given access is allowed or not, in terms of the same-origin security policy. 1061 1074 1062 1075 Usage: [CheckSecurity] can be specified on interfaces. 1063 [DoNotCheckSecurity] can be specified on methods or attributes which belong to interfaces whichhave [CheckSecurity].1076 [DoNotCheckSecurity] can be specified on methods or attributes that belong to interfaces that have [CheckSecurity]. 1064 1077 [DoNotCheckSecurityOnGetter] and [DoNotCheckSecurityOnSetter] can be specified on attributes 1065 which belong to interfaces whichhave [CheckSecurity]:1078 that belong to interfaces that have [CheckSecurity]: 1066 1079 {{{ 1067 1080 interface [ … … 1077 1090 }}} 1078 1091 1079 Consider the case where you access window.parent from inside iframe whichcomes from a different origin.1092 Consider the case where you access window.parent from inside an iframe that comes from a different origin. 1080 1093 While it is allowed to access window.parent, it is not allowed to access window.parent.document. 1081 1094 In such cases, you need to specify [CheckSecurity] in order to check 1082 whether a given Frame is allowed to access the attribute or method.1095 whether a given DOM object is allowed to access the attribute or method, in terms of the same-origin security policy. 1083 1096 This is really important for security. 1084 1097 1085 If you specify [CheckSecurity] on an interface, the security check is enabled on all the attributes and methods inthe interface.1086 To disable the security check for some attribute or method, you can use1087 [DoNotCheckSecurity], [DoNotCheckSecurityOnGetter] or [DoNotCheckSecurityOnSetter].1098 If you specify [CheckSecurity] on an interface, the security check is enabled on all the attributes and methods of the interface. 1099 To disable the security check for particular attributes or methods, 1100 you can use [DoNotCheckSecurity], [DoNotCheckSecurityOnGetter] or [DoNotCheckSecurityOnSetter]. 1088 1101 1089 1102 * [DoNotCheckSecurity] on a method disables the security check for the method. … … 1095 1108 == [CheckSecurityForNode](m,a) == #CheckSecurityForNode 1096 1109 1097 Summary: It checks if a given Node access is allowed in terms of security.1098 1099 Usage: [CheckSecurityForNode] can be specified on methods andattributes:1110 Summary: [CheckSecurityForNode] checks whether a given access to Node is allowed or not, in terms of the same-origin security policy. 1111 1112 Usage: [CheckSecurityForNode] can be specified on methods or attributes: 1100 1113 {{{ 1101 1114 attribute [CheckSecurityForNode] Node contentDocument; … … 1103 1116 }}} 1104 1117 1105 In terms of security, node.contentDocument should return undefined if the parent frame and the child frame are from different origins.1106 If the security check is ne eded, you should specify [CheckSecurityForNode].1118 In terms of the same-origin security policy, node.contentDocument should return undefined if the parent frame and the child frame are from different origins. 1119 If the security check is necessary, you should specify [CheckSecurityForNode]. 1107 1120 This is really important for security. 1108 1121 1109 == 1122 == [IndexedGetter](i) == #IndexedGetter 1110 1123 1111 1124 * [http://dev.w3.org/2006/webapi/WebIDL/#idl-indexed-properties The spec of indexed properties] (Note: The WebKit behavior explained below is different from the spec) … … 1122 1135 1123 1136 Indexed getters define the behavior when XXX[i] is evaluated. 1124 The bindings code is generated automatically so that XXX[i] behaves equivalent to XXX.item(i). 1125 1126 == [CustomIndexedSetter](i) == #CustomIndexedSetter 1137 For example, if XXX is an array-type interface, it should have indexed getters (and setters). 1138 The bindings code for indexed getters is generated automatically so that XXX[i] behaves equivalent to XXX.item(i). 1139 1140 == [CustomIndexedSetter](i) == #CustomIndexedSetter 1127 1141 1128 1142 * [http://dev.w3.org/2006/webapi/WebIDL/#idl-indexed-properties The spec of indexed properties] (Note: The WebKit behavior explained below is different from the spec) … … 1139 1153 1140 1154 Indexed setters define the behavior when "XXX[i] = ..." is evaluated. 1141 [CustomIndexedSetter] allows you to write the custom bindings. 1155 For example, if XXX is an array-type interface, it should have indexed (getters and) setters. 1156 [CustomIndexedSetter] allows you to write the custom bindings, as follows. 1142 1157 1143 1158 * JavaScriptCore: You can write JSXXX::indexSetter(...) in WebCore/bindings/js/JSXXXCustom.cpp: … … 1149 1164 } 1150 1165 }}} 1151 * In V8: You can write V8XXX::indexedProperty Getter(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1152 1153 {{{ 1154 v8::Handle<v8::Value> V8XXX::indexedProperty Getter(uint32_t index, const v8::AccessorInfo& info)1166 * In V8: You can write V8XXX::indexedPropertySetter(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1167 1168 {{{ 1169 v8::Handle<v8::Value> V8XXX::indexedPropertySetter(uint32_t index, const v8::AccessorInfo& info) 1155 1170 { 1156 1171 ...; … … 1172 1187 }}} 1173 1188 1174 Named getters define the behavior when XXX.foooooooo is evaluated, where foooooooo is not an attribute of a given interface.1175 The bindings code is generated automatically so that XXX.foooooooo behaves equivalent to XXX.namedItem(i).1189 Named getters define the behavior when XXX.foooooooo is evaluated, where foooooooo is not an attribute of XXX. 1190 The bindings code for named getters is generated automatically so that XXX.foooooooo behaves equivalent to XXX.namedItem(i). 1176 1191 1177 1192 == [CustomNamedGetter](i), [CustomNamedSetter](i) == #CustomNamedGetter … … 1179 1194 * [http://dev.w3.org/2006/webapi/WebIDL/#idl-named-properties The spec of named properties] (Note: The WebKit behavior explained below is different from the spec) 1180 1195 1181 Summary: [CustomNamedGetter] /[CustomNamedSetter] allows you to write custom bindings for a getter/setter of named properties.1196 Summary: [CustomNamedGetter] or [CustomNamedSetter] allows you to write custom bindings for a getter or setter of named properties. 1182 1197 1183 1198 Usage: They can be specified on interfaces: … … 1190 1205 }}} 1191 1206 1192 Named getters define the behavior when XXX.foooooooo is evaluated, where foooooooo is not an attribute of a given interface.1207 Named getters define the behavior when XXX.foooooooo is evaluated, where foooooooo is not an attribute of XXX. 1193 1208 Named setters define the behavior when "XXX.foooooooo = ..." is evaluated. 1194 [CustomNamedGetter] and [CustomNamedSetter] allow you to write the custom bindings.1209 [CustomNamedGetter] or [CustomNamedSetter] allow you to write the custom bindings, as follows: 1195 1210 1196 1211 * [CustomNamedGetter] in JavaScriptCore: You can write JSXXX::canGetItemsForName(...) and JSXXX::nameGetter(...) in WebCore/bindings/js/JSXXXCustom.cpp: 1197 1212 1198 1213 {{{ 1199 bool JSXXX::canGetItemsForName(ExecState* , XXX* impl, const Identifier& propertyName)1214 bool JSXXX::canGetItemsForName(ExecState* exec, XXX* impl, const Identifier& propertyName) 1200 1215 { 1201 1216 ...; … … 1210 1225 1211 1226 {{{ 1212 v8::Handle<v8::Value> V8XXX::namedPropertyGetter(v8::Local<v8::String> , v8::Local<v8::Value>, const v8::AccessorInfo&)1227 v8::Handle<v8::Value> V8XXX::namedPropertyGetter(v8::Local<v8::String> name, const v8::AccessorInfo& info) 1213 1228 { 1214 1229 ...; … … 1218 1233 1219 1234 {{{ 1220 bool JSXXX::putDelegate(ExecState* exec, const Identifier& propertyName, JSValue value, PutPropertySlot& )1235 bool JSXXX::putDelegate(ExecState* exec, const Identifier& propertyName, JSValue value, PutPropertySlot& slot) 1221 1236 { 1222 1237 ...; … … 1226 1241 1227 1242 {{{ 1228 v8::Handle<v8::Value> V8XXX::namedPropertySetter(v8::Local<v8::String> , v8::Local<v8::Value>, const v8::AccessorInfo&)1243 v8::Handle<v8::Value> V8XXX::namedPropertySetter(v8::Local<v8::String> name, v8::Local<v8::Value> value, const v8::AccessorInfo& info) 1229 1244 { 1230 1245 ...; … … 1236 1251 Summary: ADD SUMMARY 1237 1252 1238 Usage: [EventTarget] can be specified on interfaces .1253 Usage: [EventTarget] can be specified on interfaces: 1239 1254 {{{ 1240 1255 interface [ … … 1291 1306 Summary: ADD SUMMARY 1292 1307 1293 Usage: [V8DependentLifeTime] can be specified on interfaces .1308 Usage: [V8DependentLifeTime] can be specified on interfaces: 1294 1309 {{{ 1295 1310 interface [ … … 1398 1413 == [JSCustomToNativeObject](i), [JSCustomFinalize](i), [JSCustomIsReachable](i), [JSCustomMarkFunction](i), [JSCustomNamedGetterOnPrototype](i), [JSCustomPushEventHandlerScope](i), [JSCustomDefineOwnProperty](i), [JSCustomDefineOwnPropertyOnPrototype](i), [JSCustomGetOwnPropertySlotAndDescriptor](i) == #JSCustomToNativeObject 1399 1414 1400 Summary: They allow you to write custom code for the JavaScriptCore code whichwould be generated automatically by default.1415 Summary: They allow you to write custom code for the JavaScriptCore code that would be generated automatically by default. 1401 1416 1402 1417 Usage: They can be specified on interfaces: … … 1501 1516 Summary: They force JavaScriptCore bindings to generate JavaScriptCore specific methods even if a given interface has a parent interface. 1502 1517 1503 Usage: They can be specified on interfaces whichdo not have a parent interface:1518 Usage: They can be specified on interfaces that do not have a parent interface: 1504 1519 {{{ 1505 1520 interface [ … … 1562 1577 Summary: ADD SUMMARY 1563 1578 1564 Usage: [JSNoStaticTables] can be specified on interfaces .1579 Usage: [JSNoStaticTables] can be specified on interfaces: 1565 1580 {{{ 1566 1581 interface [