Changes between Version 96 and Version 97 of WebKitIDL
- Timestamp:
- May 8, 2013, 1:14:45 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WebKitIDL
v96 v97 1035 1035 This is really important for security. 1036 1036 1037 == [IndexedGetter](i) == #IndexedGetter1037 == `[IndexedGetter]`(i) == #IndexedGetter 1038 1038 1039 1039 * [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) 1040 1040 1041 Summary: [IndexedGetter]means that a given interface should have a getter of indexed properties.1042 1043 Usage: [IndexedGetter]can be specified on interfaces:1041 Summary: `[IndexedGetter]` means that a given interface should have a getter of indexed properties. 1042 1043 Usage: `[IndexedGetter]` can be specified on interfaces: 1044 1044 {{{ 1045 1045 interface [ … … 1049 1049 }}} 1050 1050 1051 Indexed getters define the behavior when XXX[i]is evaluated.1052 For example, if XXXis an array-type interface, it should have indexed getters (and setters).1053 The bindings code for indexed getters is generated automatically so that XXX[i] behaves equivalent to XXX.item(i).1054 1055 == [V8CustomIndexedGetter](i) == #V8CustomIndexedGetter1056 1057 Summary: [V8CustomIndexedGetter]allows you to write custom bindings for a getter of indexed properties.1058 1059 Usage: [V8CustomIndexedGetter]can be specified on interfaces:1051 Indexed getters define the behavior when `XXX[i]` is evaluated. 1052 For example, if `XXX` is an array-type interface, it should have indexed getters (and setters). 1053 The bindings code for indexed getters is generated automatically so that `XXX[i]` behaves equivalent to `XXX.item(i)`. 1054 1055 == `[V8CustomIndexedGetter]`(i) == #V8CustomIndexedGetter 1056 1057 Summary: `[V8CustomIndexedGetter]` allows you to write custom bindings for a getter of indexed properties. 1058 1059 Usage: `[V8CustomIndexedGetter]` can be specified on interfaces: 1060 1060 {{{ 1061 1061 interface [ … … 1067 1067 Interface that have V8CustomIndexedGetter attribute must have also IndexedGetter attribute. 1068 1068 1069 == [CustomIndexedSetter](i) == #CustomIndexedSetter1069 == `[CustomIndexedSetter]`(i) == #CustomIndexedSetter 1070 1070 1071 1071 * [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) 1072 1072 1073 Summary: [CustomIndexedSetter]allows you to write custom bindings for a setter of indexed properties.1073 Summary: `[CustomIndexedSetter]` allows you to write custom bindings for a setter of indexed properties. 1074 1074 1075 1075 Usage: [CustomIndexedSetter] can be specified on interfaces: … … 1083 1083 Indexed setters define the behavior when "XXX[i] = ..." is evaluated. 1084 1084 For example, if XXX is an array-type interface, it should have indexed (getters and) setters. 1085 [CustomIndexedSetter]allows you to write the custom bindings, as follows.1086 1087 * JavaScriptCore: You can write custom JSXXX::indexSetter(...)in WebCore/bindings/js/JSXXXCustom.cpp:1085 `[CustomIndexedSetter]` allows you to write the custom bindings, as follows. 1086 1087 * JavaScriptCore: You can write custom `JSXXX::indexSetter(...)` in WebCore/bindings/js/JSXXXCustom.cpp: 1088 1088 1089 1089 {{{ … … 1093 1093 } 1094 1094 }}} 1095 * In V8: You can write custom V8XXX::indexedPropertySetter(...)in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1095 * In V8: You can write custom `V8XXX::indexedPropertySetter(...)` in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1096 1096 1097 1097 {{{ … … 1102 1102 }}} 1103 1103 1104 == [NamedGetter](i) == #NamedGetter1104 == `[NamedGetter]`(i) == #NamedGetter 1105 1105 1106 1106 * [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) 1107 1107 1108 Summary: [NamedGetter]means that a given interface should have a getter of named properties.1109 1110 Usage: [NamedGetter]can be specified on interfaces:1108 Summary: `[NamedGetter]` means that a given interface should have a getter of named properties. 1109 1110 Usage: `[NamedGetter]` can be specified on interfaces: 1111 1111 {{{ 1112 1112 interface [ … … 1119 1119 The bindings code for named getters is generated automatically so that XXX.foooooooo behaves equivalent to XXX.namedItem(i). 1120 1120 1121 == [CustomNamedGetter](i), [CustomNamedSetter](i) == #CustomNamedGetter1121 == `[CustomNamedGetter]`(i), `[CustomNamedSetter]`(i) == #CustomNamedGetter 1122 1122 1123 1123 * [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) 1124 1124 1125 Summary: [CustomNamedGetter] or [CustomNamedSetter]allows you to write custom bindings for a getter or setter of named properties.1125 Summary: `[CustomNamedGetter]` or `[CustomNamedSetter]` allows you to write custom bindings for a getter or setter of named properties. 1126 1126 1127 1127 Usage: They can be specified on interfaces: … … 1136 1136 Named getters define the behavior when XXX.foooooooo is evaluated, where foooooooo is not an attribute of XXX. 1137 1137 Named setters define the behavior when "XXX.foooooooo = ..." is evaluated. 1138 [CustomNamedGetter] or [CustomNamedSetter]allow you to write the custom bindings, as follows:1139 1140 * [CustomNamedGetter] in JavaScriptCore: You can write custom JSXXX::canGetItemsForName(...) and JSXXX::nameGetter(...)in WebCore/bindings/js/JSXXXCustom.cpp:1138 `[CustomNamedGetter]` or `[CustomNamedSetter]` allow you to write the custom bindings, as follows: 1139 1140 * `[CustomNamedGetter]` in JavaScriptCore: You can write custom `JSXXX::canGetItemsForName(...)` and `JSXXX::nameGetter(...)` in WebCore/bindings/js/JSXXXCustom.cpp: 1141 1141 1142 1142 {{{ … … 1151 1151 } 1152 1152 }}} 1153 * [CustomNamedGetter] in V8: You can write custom V8XXX::namedPropertyGetter(...)in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1153 * `[CustomNamedGetter]` in V8: You can write custom `V8XXX::namedPropertyGetter(...)` in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1154 1154 1155 1155 {{{ … … 1159 1159 } 1160 1160 }}} 1161 * [CustomNamedSetter] in JavaScriptCore: You can write custom JSXXX::putDelegate(...)in WebCore/bindings/js/JSXXXCustom.cpp:1161 * `[CustomNamedSetter]` in JavaScriptCore: You can write custom `JSXXX::putDelegate(...)` in WebCore/bindings/js/JSXXXCustom.cpp: 1162 1162 1163 1163 {{{ … … 1167 1167 } 1168 1168 }}} 1169 * [CustomNamedSetter] in V8: You can write custom V8XXX::namedPropertySetter(...)in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1169 * `[CustomNamedSetter]` in V8: You can write custom `V8XXX::namedPropertySetter(...)` in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1170 1170 1171 1171 {{{ … … 1176 1176 }}} 1177 1177 1178 == [InterfaceName](i) == #InterfaceName1179 1180 Summary: If you want to expose a different interface name to JavaScript, you can specify the name by [InterfaceName].1181 1182 Usage: The possible usage is [InterfaceName=X], where Xis the interface name exposed to JavaScript.1183 [InterfaceName]can be specified on interfaces:1178 == `[InterfaceName]`(i) == #InterfaceName 1179 1180 Summary: If you want to expose a different interface name to JavaScript, you can specify the name by `[InterfaceName]`. 1181 1182 Usage: The possible usage is `[InterfaceName=X]`, where `X` is the interface name exposed to JavaScript. 1183 `[InterfaceName]` can be specified on interfaces: 1184 1184 {{{ 1185 1185 interface [ … … 1189 1189 }}} 1190 1190 1191 Without [InterfaceName=...], the interface name exposed to JavaScript becomes the same as the interface name in an IDL file.1192 If you want change it based on the spec, you can use [InterfaceName=...].1191 Without `[InterfaceName=...]`, the interface name exposed to JavaScript becomes the same as the interface name in an IDL file. 1192 If you want change it based on the spec, you can use `[InterfaceName=...]`. 1193 1193 In the above example, `window.toString()` will return `"[object Window]"` in JavaScript. 1194 1194 1195 == [EventTarget](i) FIXME == #EventTarget1195 == `[EventTarget]`(i) FIXME == #EventTarget 1196 1196 1197 1197 Summary: ADD SUMMARY 1198 1198 1199 Usage: [EventTarget]can be specified on interfaces:1199 Usage: `[EventTarget]` can be specified on interfaces: 1200 1200 {{{ 1201 1201 interface [ … … 1207 1207 ADD EXPLANATIONS 1208 1208 1209 == [DoNotCheckConstants](i) == #DoNotCheckConstants1210 1211 Summary: [DoNotCheckConstants]indicates that constant values in an IDL file can be different from constant values in WebCore implementation.1212 1213 Usage: [DoNotCheckConstants]can be specified on interfaces:1209 == `[DoNotCheckConstants]`(i) == #DoNotCheckConstants 1210 1211 Summary: `[DoNotCheckConstants]` indicates that constant values in an IDL file can be different from constant values in WebCore implementation. 1212 1213 Usage: `[DoNotCheckConstants]` can be specified on interfaces: 1214 1214 {{{ 1215 1215 interface [ … … 1221 1221 }}} 1222 1222 1223 By default (i.e. without [DoNotCheckConstants]), compile-time assertions are inserted to check if the constant values defined in IDL files1223 By default (i.e. without `[DoNotCheckConstants]`), compile-time assertions are inserted to check if the constant values defined in IDL files 1224 1224 are equal to the constant values in WebCore implementation. 1225 1225 In the above example, if NOT_FOUND_ERR were implemented as 100 in WebCore, the build will fail. … … 1228 1228 and thus the values in WebCore implementation should be equal to the values defined in the spec. 1229 1229 If you really want to introduce non-speced constant values and allow different values between IDL files and WebCore implementation, 1230 you can specify [DoNotCheckConstants]to skip the compile-time assertions.1231 1232 == [ActiveDOMObject](i) == #ActiveDOMObject1233 1234 Summary: [ActiveDOMObject]indicates that a given DOM object should be kept alive as long as the DOM object has pending activities.1235 1236 Usage: [ActiveDOMObject]can be specified on interfaces:1230 you can specify `[DoNotCheckConstants]` to skip the compile-time assertions. 1231 1232 == `[ActiveDOMObject]`(i) == #ActiveDOMObject 1233 1234 Summary: `[ActiveDOMObject]` indicates that a given DOM object should be kept alive as long as the DOM object has pending activities. 1235 1236 Usage: `[ActiveDOMObject]` can be specified on interfaces: 1237 1237 {{{ 1238 1238 interface [ … … 1242 1242 }}} 1243 1243 1244 If a given DOM object needs to be kept alive as long as the DOM object has pending activities, you need to specify [ActiveDOMObject].1245 For example, [ActiveDOMObject]can be used when the DOM object is expecting events to be raised in the future.1246 1247 If you use [ActiveDOMObject], the corresponding WebCore class needs to inherit ActiveDOMObject.1244 If a given DOM object needs to be kept alive as long as the DOM object has pending activities, you need to specify `[ActiveDOMObject]`. 1245 For example, `[ActiveDOMObject]` can be used when the DOM object is expecting events to be raised in the future. 1246 1247 If you use `[ActiveDOMObject]`, the corresponding WebCore class needs to inherit ActiveDOMObject. 1248 1248 For example, in case of XMLHttpRequest, WebCore/xml/XMLHttpRequest.h would look like this: 1249 1249 {{{ … … 1254 1254 Then you need to implement the virtual methods of the ActiveDOMObject class, e.g. contextDestroyed(), canSuspend(), suspend(), resume() and stop(). 1255 1255 1256 If an interface X has [ActiveDOMObject]and an interface Y inherits the interface X,1257 then the interface Y should also have [ActiveDOMObject].1258 1259 == [V8DependentLifeTime](i) FIXME == #V8DependentLifeTime1256 If an interface X has `[ActiveDOMObject]` and an interface Y inherits the interface X, 1257 then the interface Y should also have `[ActiveDOMObject]`. 1258 1259 == `[V8DependentLifeTime]`(i) FIXME == #V8DependentLifeTime 1260 1260 1261 1261 Summary: ADD SUMMARY 1262 1262 1263 Usage: [V8DependentLifeTime]can be specified on interfaces:1263 Usage: `[V8DependentLifeTime]` can be specified on interfaces: 1264 1264 {{{ 1265 1265 interface [ … … 1271 1271 ADD EXPLANATIONS 1272 1272 1273 == [CustomEnumerateProperty](i), [CustomDeleteProperty](i) == #CustomEnumerateProperty1274 1275 Summary: [CustomEnumerateProperty]allows you to write custom bindings for the case where properties of a given interface are enumerated.1276 [CustomDeleteProperty]allows you to write custom bindings for the case where a property of a given interface is deleted.1273 == `[CustomEnumerateProperty]`(i), `[CustomDeleteProperty]`(i) == #CustomEnumerateProperty 1274 1275 Summary: `[CustomEnumerateProperty]` allows you to write custom bindings for the case where properties of a given interface are enumerated. 1276 `[CustomDeleteProperty]` allows you to write custom bindings for the case where a property of a given interface is deleted. 1277 1277 1278 1278 Usage: They can be specified on interfaces: … … 1285 1285 }}} 1286 1286 1287 * [CustomEnumerateProperty]in JavaScriptCore: You can write custom bindings when properties of XXX are enumerated.1288 Specifically, you can write custom JSXXX::getOwnPropertyNames(...)in WebCore/bindings/js/JSXXXCustom.cpp:1287 * `[CustomEnumerateProperty]` in JavaScriptCore: You can write custom bindings when properties of XXX are enumerated. 1288 Specifically, you can write custom `JSXXX::getOwnPropertyNames(...)` in WebCore/bindings/js/JSXXXCustom.cpp: 1289 1289 1290 1290 {{{ … … 1295 1295 }}} 1296 1296 1297 * [CustomEnumerateProperty] in V8: You can write custom bindings as V8XXX::namedPropertyQuery(...) and V8XXX::namedPropertyEnumerator(...)in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1297 * `[CustomEnumerateProperty]` in V8: You can write custom bindings as `V8XXX::namedPropertyQuery(...)` and `V8XXX::namedPropertyEnumerator(...)` in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1298 1298 1299 1299 {{{ … … 1309 1309 }}} 1310 1310 1311 * [CustomDeleteProperty]in JavaScriptCore: You can write custom bindings for the case where a property of XXX is deleted.1312 Specifically, you can write custom JSXXX::deleteProperty(...)in WebCore/bindings/js/JSXXXCustom.cpp:1311 * `[CustomDeleteProperty]` in JavaScriptCore: You can write custom bindings for the case where a property of XXX is deleted. 1312 Specifically, you can write custom `JSXXX::deleteProperty(...)` in WebCore/bindings/js/JSXXXCustom.cpp: 1313 1313 1314 1314 {{{ … … 1319 1319 }}} 1320 1320 1321 * [CustomDeleteProperty] in V8: You can write custom bindings as V8XXX::namedPropertyDeleter(...)in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1321 * `[CustomDeleteProperty]` in V8: You can write custom bindings as `V8XXX::namedPropertyDeleter(...)` in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1322 1322 1323 1323 {{{ … … 1328 1328 }}} 1329 1329 1330 == [IsWorkerContext](i) == #IsWorkerContext1331 1332 Summary: [IsWorkerContext]indicates that a given interface is a WorkerContext-related interface.1333 1334 Usage: [IsWorkerContext]can be specified on WorkerContext-related interfaces only:1330 == `[IsWorkerContext]`(i) == #IsWorkerContext 1331 1332 Summary: `[IsWorkerContext]` indicates that a given interface is a WorkerContext-related interface. 1333 1334 Usage: `[IsWorkerContext]` can be specified on WorkerContext-related interfaces only: 1335 1335 {{{ 1336 1336 interface [ … … 1340 1340 }}} 1341 1341 1342 == [TransferList](p) == #TransferList1343 1344 Summary: [TransferList]allows a SerializedScriptValue parameter used1342 == `[TransferList]`(p) == #TransferList 1343 1344 Summary: `[TransferList]` allows a SerializedScriptValue parameter used 1345 1345 with the structured clone algorithm to specify another parameter used 1346 1346 to pass the transfer list. 1347 1347 1348 Usage: The possible usage is [TransferList=XXX] where XXXis another1348 Usage: The possible usage is `[TransferList=XXX]` where `XXX` is another 1349 1349 parameter in the same method signature as the SerializedScriptValue 1350 1350 parameter on which the modifier is placed. The referenced parameter … … 1371 1371 }}} 1372 1372 1373 == [TypedArray](i), [ConstructorTemplate=TypedArray](i) == #TypedArray1373 == `[TypedArray]`(i), [ConstructorTemplate=TypedArray](i) == #TypedArray 1374 1374 1375 1375 * [http://www.khronos.org/registry/typedarray/specs/latest/#7 The spec of TypedArray] … … 1378 1378 TypedArray implements ArrayBufferView. Each of the typed array types has the following constructors, properties, constants and methods. 1379 1379 1380 Usage: [TypedArray] must be specified on interfaces in conjunction with [ConstructorTemplate=TypedArray]:1380 Usage: `[TypedArray]` must be specified on interfaces in conjunction with `[ConstructorTemplate=TypedArray]`: 1381 1381 Example: 1382 1382 … … 1390 1390 }}} 1391 1391 1392 TypedArray=*Allows us to specify any valid typed array view type.1393 TypedArray interfaces require special bindings code, you need to use [ConstructorTemplate=TypedArray] instead of normal [Constructor].1394 1395 == [CustomCall](i) == #CustomCall1396 1397 Summary: [CustomCall] allows you to write custom bindings for call(...)of a given interface.1398 1399 Usage: [CustomCall]can be specified on interfaces:1392 `TypedArray=*` Allows us to specify any valid typed array view type. 1393 TypedArray interfaces require special bindings code, you need to use `[ConstructorTemplate=TypedArray]` instead of normal `[Constructor]`. 1394 1395 == `[CustomCall]`(i) == #CustomCall 1396 1397 Summary: `[CustomCall]` allows you to write custom bindings for `call(...)` of a given interface. 1398 1399 Usage: `[CustomCall]` can be specified on interfaces: 1400 1400 {{{ 1401 1401 interface [ … … 1405 1405 }}} 1406 1406 1407 If you want to write custom bindings for XXX.call(...), you can use [CustomCall].1408 1409 * JavaScriptCore: You can write custom JSXXX::getCallData(...)in WebCore/bindings/js/JSXXXCustom.cpp:1407 If you want to write custom bindings for XXX.call(...), you can use `[CustomCall]`. 1408 1409 * JavaScriptCore: You can write custom `JSXXX::getCallData(...)` in WebCore/bindings/js/JSXXXCustom.cpp: 1410 1410 1411 1411 {{{ … … 1415 1415 } 1416 1416 }}} 1417 * V8: You can write custom V8XXX::callAsFunctionCallback(...)in WebCore/bindings/v8/custom/V8XXXCustom.cpp:1417 * V8: You can write custom `V8XXX::callAsFunctionCallback(...)` in WebCore/bindings/v8/custom/V8XXXCustom.cpp: 1418 1418 1419 1419 {{{ … … 1424 1424 }}} 1425 1425 1426 == [JSCustomToNativeObject](i), [JSCustomFinalize](i), [JSCustomIsReachable](i), [JSCustomMarkFunction](i), [JSCustomNamedGetterOnPrototype](i), [JSCustomPushEventHandlerScope](i), [JSCustomDefineOwnProperty](i), [JSCustomDefineOwnPropertyOnPrototype](i), [JSCustomGetOwnPropertySlotAndDescriptor](i) == #JSCustomToNativeObject1426 == `[JSCustomToNativeObject]`(i), `[JSCustomFinalize]`(i), `[JSCustomIsReachable]`(i), `[JSCustomMarkFunction]`(i), `[JSCustomNamedGetterOnPrototype]`(i), `[JSCustomPushEventHandlerScope]`(i), `[JSCustomDefineOwnProperty]`(i), `[JSCustomDefineOwnPropertyOnPrototype]`(i), `[JSCustomGetOwnPropertySlotAndDescriptor]`(i) == #JSCustomToNativeObject 1427 1427 1428 1428 Summary: They allow you to write custom bindings for the JavaScriptCore-specific code that would be generated automatically by default. … … 1447 1447 Refer to use cases in WebCore/bindings/js/JSXXXCustom.cpp for more details. 1448 1448 1449 * [JSCustomToNativeObject]: You can write custom toXXX(...):1449 * `[JSCustomToNativeObject]`: You can write custom `toXXX(...)`: 1450 1450 1451 1451 {{{ … … 1455 1455 } 1456 1456 }}} 1457 * [JSCustomFinalize]: You can write custom JSXXXOwner::finalize(...):1457 * `[JSCustomFinalize]`: You can write custom `JSXXXOwner::finalize(...)`: 1458 1458 1459 1459 {{{ … … 1463 1463 } 1464 1464 }}} 1465 * [JSCustomIsReachable]: You can write custom JSXXXOwner::isReachableFromOpaqueRoots(...):1465 * `[JSCustomIsReachable]`: You can write custom `JSXXXOwner::isReachableFromOpaqueRoots(...)`: 1466 1466 1467 1467 {{{ … … 1471 1471 } 1472 1472 }}} 1473 * [JSCustomMarkFunction]: You can write custom JSXXX::visitChildren(...):1473 * `[JSCustomMarkFunction]`: You can write custom `JSXXX::visitChildren(...)`: 1474 1474 1475 1475 {{{ … … 1479 1479 } 1480 1480 }}} 1481 * [JSCustomNamedGetterOnPrototype]: You can write custom JSXXXPrototype::putDelegate(...):1481 * `[JSCustomNamedGetterOnPrototype]`: You can write custom `JSXXXPrototype::putDelegate(...)`: 1482 1482 1483 1483 {{{ … … 1487 1487 } 1488 1488 }}} 1489 * [JSCustomPushEventHandlerScope]: You can write custom JSXXX::pushEventHandlerScope(...):1489 * `[JSCustomPushEventHandlerScope]`: You can write custom `JSXXX::pushEventHandlerScope(...)`: 1490 1490 1491 1491 {{{ … … 1495 1495 } 1496 1496 }}} 1497 * [JSCustomDefineOwnProperty]: You can write custom JSXXX::defineOwnProperty(...):1497 * `[JSCustomDefineOwnProperty]`: You can write custom `JSXXX::defineOwnProperty(...)`: 1498 1498 1499 1499 {{{ … … 1503 1503 } 1504 1504 }}} 1505 * [JSCustomDefineOwnPropertyOnPrototype]: You can write custom JSXXXPrototype::defineOwnProperty(...):1505 * `[JSCustomDefineOwnPropertyOnPrototype]`: You can write custom `JSXXXPrototype::defineOwnProperty(...)`: 1506 1506 1507 1507 {{{ … … 1511 1511 } 1512 1512 }}} 1513 * [JSCustomGetOwnPropertySlotAndDescriptor]: You can write custom JSXXX::getOwnPropertySlotDelegate(...) and JSXXX::getOwnPropertyDescriptorDelegate(...):1513 * `[JSCustomGetOwnPropertySlotAndDescriptor]`: You can write custom `JSXXX::getOwnPropertySlotDelegate(...)` and `JSXXX::getOwnPropertyDescriptorDelegate(...)`: 1514 1514 1515 1515 {{{ … … 1525 1525 }}} 1526 1526 1527 == [JSGenerateToJSObject](i), [JSGenerateToNativeObject](i) == #JSGenerateToJSObject1527 == `[JSGenerateToJSObject]`(i), `[JSGenerateToNativeObject]`(i) == #JSGenerateToJSObject 1528 1528 1529 1529 Summary: They force JavaScriptCore bindings to generate JavaScriptCore-specific methods, even if a given interface has a parent interface. … … 1538 1538 }}} 1539 1539 1540 toJS(...), isReachableFromOpaqueRoots(...) or toXXX()is not generated if XXX has a parent interface.1540 `toJS(...)`, `isReachableFromOpaqueRoots(...)` or `toXXX()` is not generated if XXX has a parent interface. 1541 1541 If you want to generate it even if XXX does not have a parent interface, you can specify 1542 [JSGenerateToJSObject] or [JSGenerateToNativeObject], respectively.1543 1544 == [JSGenerateIsReachable](i) == #JSGenerateIsReachable1542 `[JSGenerateToJSObject]` or `[JSGenerateToNativeObject]`, respectively. 1543 1544 == `[JSGenerateIsReachable]`(i) == #JSGenerateIsReachable 1545 1545 1546 1546 Summary: This generates code that determines if a wrapper is reachable. 1547 1547 1548 Usage: The JSGenerateIsReachable can be specified on the interface. This attribute is ignored if CustomIsReachableis present.1548 Usage: The `JSGenerateIsReachable` can be specified on the interface. This attribute is ignored if `CustomIsReachable` is present. 1549 1549 1550 1550 {{{ … … 1555 1555 }}} 1556 1556 1557 The code generates a function called XXX::isReachableFromOpaqueRootswhich returns a boolean if the wrapper is reachable.1557 The code generates a function called `XXX::isReachableFromOpaqueRoots` which returns a boolean if the wrapper is reachable. 1558 1558 1559 1559 The currently valid values are: … … 1616 1616 } 1617 1617 }}} 1618 == [GenerateIsReachable](i) == #GenerateIsReachable1619 1620 Summary: This is the shared version of [JSGenerateIsReachable] and V8GenerateIsReachable. The accepted values are the intersection of those two.1618 == `[GenerateIsReachable]`(i) == #GenerateIsReachable 1619 1620 Summary: This is the shared version of `[JSGenerateIsReachable]` and `V8GenerateIsReachable`. The accepted values are the intersection of those two. 1621 1621 1622 1622 - ImplElementRoot 1623 1623 - ImplBaseRoot 1624 1624 1625 == [JSCustomHeader](i) == #JSCustomHeader1626 1627 Summary: [JSCustomHeader]allows you to write a custom header for a given interface.1628 1629 Usage: [JSCustomHeader]can be specified on interfaces:1625 == `[JSCustomHeader]`(i) == #JSCustomHeader 1626 1627 Summary: `[JSCustomHeader]` allows you to write a custom header for a given interface. 1628 1629 Usage: `[JSCustomHeader]` can be specified on interfaces: 1630 1630 {{{ 1631 1631 interface [ … … 1636 1636 1637 1637 By default, JSXXX.h and JSXXX.cpp are generated automatically. 1638 By specifying [Custom*], you can write custom bindings in WebCore/bindings/js/JSXXXCustom.cpp.1639 In addition, by specifying [JSCustomHeader], you can write custom header in WebCore/bindings/js/JSXXXCustom.h, which will be included by JSXXX.h.1640 1641 == [JSLegacyParent](i) == #JSLegacyParent1642 1643 Summary: [JSLegacyParent]explicitly controls the parent interface of a given interface.1644 1645 Usage: [JSLegacyParent]can be specified on interfaces that do not have a parent interface:1638 By specifying `[Custom*]`, you can write custom bindings in WebCore/bindings/js/JSXXXCustom.cpp. 1639 In addition, by specifying `[JSCustomHeader]`, you can write custom header in WebCore/bindings/js/JSXXXCustom.h, which will be included by JSXXX.h. 1640 1641 == `[JSLegacyParent]`(i) == #JSLegacyParent 1642 1643 Summary: `[JSLegacyParent]` explicitly controls the parent interface of a given interface. 1644 1645 Usage: `[JSLegacyParent]` can be specified on interfaces that do not have a parent interface: 1646 1646 {{{ 1647 1647 interface [ … … 1651 1651 }}} 1652 1652 1653 Even if a given interface does not have a parent interface, you can specify a parent interface using [JSLegacyParent].1654 1655 == [JSInlineGetOwnPropertySlot](i) == #JSInlineGetOwnPropertySlot1656 1657 Summary: For performance, [JSInlineGetOwnPropertySlot] makes getOwnPropertySlot(...) and getOwnPropertyDescriptor(...)an inline method.1658 1659 Usage: [JSInlineGetOwnPropertySlot]can be specified on interfaces:1653 Even if a given interface does not have a parent interface, you can specify a parent interface using `[JSLegacyParent]`. 1654 1655 == `[JSInlineGetOwnPropertySlot]`(i) == #JSInlineGetOwnPropertySlot 1656 1657 Summary: For performance, `[JSInlineGetOwnPropertySlot]` makes `getOwnPropertySlot(...)` and `getOwnPropertyDescriptor(...)` an inline method. 1658 1659 Usage: `[JSInlineGetOwnPropertySlot]` can be specified on interfaces: 1660 1660 {{{ 1661 1661 interface [ … … 1665 1665 }}} 1666 1666 1667 == [JSNoStaticTables](i) == #JSNoStaticTables1667 == `[JSNoStaticTables]`(i) == #JSNoStaticTables 1668 1668 1669 1669 Summary: By default, there is only a single static prototype table for the interface. This flag turns off creation of the static table, and each user gets its own table. … … 1671 1671 Sharing a single static prototype table only works when a class is guaranteed to be accessed from a single heap, because the lookup code expects the key (attribute name) to have the same address across all instances of the object. For interfaces that are exposed to Workers, a single static table won't work because a given string used to look up a property on the object will lie at a different address in each heap. 1672 1672 1673 Usage: [JSNoStaticTables]can be specified on interfaces:1673 Usage: `[JSNoStaticTables]` can be specified on interfaces: 1674 1674 {{{ 1675 1675 interface [ … … 1681 1681 ADD EXPLANATIONS 1682 1682 1683 == [ObjCProtocol](i), [ObjCPolymorphic](i), [ObjCLegacyUnnamedParameters](m), [ObjCUseDefaultView](m), [ObjCImplementedAsUnsignedLongLong](a) == #ObjCProtocol1683 == `[ObjCProtocol]`(i), `[ObjCPolymorphic]`(i), `[ObjCLegacyUnnamedParameters]`(m), `[ObjCUseDefaultView]`(m), `[ObjCImplementedAsUnsignedLongLong]`(a) == #ObjCProtocol 1684 1684 1685 1685 Used by ObjC bindings only. 1686 1686 1687 == [CPPPureInterface](i) == #CPPPureInterface1687 == `[CPPPureInterface]`(i) == #CPPPureInterface 1688 1688 1689 1689 Used by CPP bindings only. 1690 1690 1691 == [CustomReturn](p) == #CustomReturn1691 == `[CustomReturn]`(p) == #CustomReturn 1692 1692 1693 1693 Used by ObjC, GObject and CPP bindings only. 1694 1694 1695 == [ArrayClass](i) == #ArrayClass1695 == `[ArrayClass]`(i) == #ArrayClass 1696 1696 1697 1697 * [http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass The spec of ArrayClass] … … 1699 1699 Summary: Allows an interface to extend JavaScript arrays. 1700 1700 1701 Usage: [ArrayClass] can be specified on interfaces. An interface may not both have [ArrayClass]and extend another interface.1701 Usage: `[ArrayClass]` can be specified on interfaces. An interface may not both have `[ArrayClass]` and extend another interface. 1702 1702 1703 1703 The bindings for the interface will have the `[[Prototype]]` of the constructor prototype set to `Array.prototype` which means that the methods defined on JavaScript arrays work on the instances of this interface. … … 1718 1718 }}} 1719 1719 1720 == [OmitConstructor], [Immutable], [MasqueradesAsUndefined], [CustomGetOwnPropertySlot], [ReplaceableConstructor], [ExtendsDOMGlobalObject], [IsIndex], [V8DoNotCheckSignature], [NumericIndexedGetter]== #OmitConstructor1720 == `[OmitConstructor]`, `[Immutable]`, `[MasqueradesAsUndefined]`, `[CustomGetOwnPropertySlot]`, `[ReplaceableConstructor]`, `[ExtendsDOMGlobalObject]`, `[IsIndex]`, `[V8DoNotCheckSignature]`, `[NumericIndexedGetter]` == #OmitConstructor 1721 1721 1722 1722 Might be deprecated. Discussion is on-going. 1723 1723 1724 == [ImplementationNameSpace]== #ImplementationNamespace1724 == `[ImplementationNameSpace]` == #ImplementationNamespace 1725 1725 1726 1726 Summary: Specifies the namespace for the corresponding native type. … … 1728 1728 By default, the namespace is WebCore. This is presently used to mark WTF types. 1729 1729 1730 Usage: [ImplementationNamespace]can be specified on interfaces:1730 Usage: `[ImplementationNamespace]` can be specified on interfaces: 1731 1731 {{{ 1732 1732 interface [ … … 1736 1736 }}} 1737 1737 1738 == [V8SkipVTableValidation], [ImplementationLacksVTable]== #V8SkipVTableValidation1738 == `[V8SkipVTableValidation]`, `[ImplementationLacksVTable]` == #V8SkipVTableValidation 1739 1739 1740 1740 Summary: Specifies that a type can not be checked as part of the V8 Bindings Integrity option. … … 1742 1742 V8 Bindings Integrity tries to ensure that free/corrupted objects are not wrapped by V8, thereby reducing their exploitability. In order for that to be the case, the implementation must have a distinct VTable pointer in its first word. 1743 1743 1744 Usage: [V8SkipVTableValidation] and [ImplementationLacksVTable]can be specified on interfaces.1744 Usage: `[V8SkipVTableValidation]` and `[ImplementationLacksVTable]` can be specified on interfaces. 1745 1745 1746 1746 {{{