The (Unofficial) Blog-style Changelog for the V8 JavaScript Engine
Currently, when the web platform wants to tell you when you've exceeded quota, it will use `DOMException` with the specific `name` property set to `QuotaExceededError`. However this does not allow carrying additional information. This proposes removing "QuotaExceededError" from the list of built-in `DOMException` names, and instead creates a class name `QuotaExceededError` from the list of built-in `DOMException` and has the additional optional properties `quota` and `requested`. We propose all instances of specs that throw "QuotaExceededError" `DOMException`s get upgraded to instead throw `QuotaExceededError`s. For now, such specs would leave the `quota` and `requested` properties at their default value of `null`, but they could eventually upgrade to include that data, if it's useful for their use case (and isn't, e.g., a privacy leak).
{
"category": "JavaScript",
"flag_name": null,
"id": 6194847180128256,
"milestone": 138,
"name": "Update QuotaExceededError to a DOMException derived interface",
"summary": "Currently, when the web platform wants to tell you when you've exceeded quota, it will use `DOMException` with the specific `name` property set to `QuotaExceededError`. However this does not allow carrying additional information.\r\n\r\nThis proposes removing \"QuotaExceededError\" from the list of built-in `DOMException` names, and instead creates a class name `QuotaExceededError` from the list of built-in `DOMException` and has the additional optional properties `quota` and `requested`. We propose all instances of specs that throw \"QuotaExceededError\" `DOMException`s get upgraded to instead throw `QuotaExceededError`s. For now, such specs would leave the `quota` and `requested` properties at their default value of `null`, but they could eventually upgrade to include that data, if it's useful for their use case (and isn't, e.g., a privacy leak)."
}
This is a Javascript API to provide an easier way to check if the Secure Payment Confirmation[1] feature is available. Currently, the only way to determine SPC’s availability is to create a PaymentRequest with the required parameters[2], which is clunky and difficult in the case where a developer wants to check for SPC before starting to process a payment. [1] https://www.w3.org/TR/secure-payment-confirmation/ [2] https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-868473461
{
"category": "JavaScript",
"flag_name": "",
"id": 5165040614768640,
"milestone": 139,
"name": "securePaymentConfirmationAvailability API",
"summary": "This is a Javascript API to provide an easier way to check if the Secure Payment Confirmation[1] feature is available. Currently, the only way to determine SPC’s availability is to create a PaymentRequest with the required parameters[2], which is clunky and difficult in the case where a developer wants to check for SPC before starting to process a payment.\r\n\r\n[1] https://www.w3.org/TR/secure-payment-confirmation/\r\n[2] https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-868473461"
}
base64 is a common way to represent arbitrary binary data as ASCII. JavaScript has Uint8Arrays to work with binary data, but no built-in mechanism to encode that data as base64, nor to take base64'd data and produce a corresponding Uint8Arrays. This is a proposal to fix that. It also adds methods for converting between hex strings and Uint8Arrays.
{
"category": "JavaScript",
"flag_name": "--js_base_64",
"id": 6281131254874112,
"milestone": 140,
"name": "Uint8Array to/from base64 and hex",
"summary": "base64 is a common way to represent arbitrary binary data as ASCII. JavaScript has Uint8Arrays to work with binary data, but no built-in mechanism to encode that data as base64, nor to take base64'd data and produce a corresponding Uint8Arrays. This is a proposal to fix that. It also adds methods for converting between hex strings and Uint8Arrays."
}