Title: [271759] trunk/LayoutTests/imported/w3c
- Revision
- 271759
- Author
- [email protected]
- Date
- 2021-01-22 13:49:57 -0800 (Fri, 22 Jan 2021)
Log Message
[WPT] [Payment Request] slight adjustment to payment-request/payment-request-constructor-thcrash.https.html
https://bugs.webkit.org/show_bug.cgi?id=220872
Reviewed by Andy Estes.
The first test in `payment-request/payment-request-constructor-thcrash.https.html` is
incorrect because duplicate items in `methodData` provided to `PaymentRequest` should throw
a `RangeError` according to step 4.3.3 of <https://www.w3.org/TR/payment-request/#constructor>.
The spec does mention in <https://www.w3.org/TR/payment-request/#conformance>
> User agents _MAY_ impose implementation-specific limits on otherwise unconstrained inputs,
> e.g., to prevent denial of service attacks, to guard against running out of memory, or to
> work around platform-specific limitations. When an input exceeds implementation-specific
> limit, the user agent _MUST_ throw, or, in the context of a promise, reject with, a
> `TypeError` optionally informing the developer of how a particular input exceeded an
> implementation-specific limit.
but does not specify whether this should happen before or after the above.
In WebKit's case, there is no "implementation-specific limit", so a `TypeError` should not
be thrown in either case.
* web-platform-tests/payment-request/payment-request-constructor-thcrash.https.html:
* web-platform-tests/payment-request/payment-request-constructor-thcrash.https-expected.txt:
Modified Paths
Diff
Modified: trunk/LayoutTests/imported/w3c/ChangeLog (271758 => 271759)
--- trunk/LayoutTests/imported/w3c/ChangeLog 2021-01-22 20:49:30 UTC (rev 271758)
+++ trunk/LayoutTests/imported/w3c/ChangeLog 2021-01-22 21:49:57 UTC (rev 271759)
@@ -1,3 +1,29 @@
+2021-01-22 Devin Rousso <[email protected]>
+
+ [WPT] [Payment Request] slight adjustment to payment-request/payment-request-constructor-thcrash.https.html
+ https://bugs.webkit.org/show_bug.cgi?id=220872
+
+ Reviewed by Andy Estes.
+
+ The first test in `payment-request/payment-request-constructor-thcrash.https.html` is
+ incorrect because duplicate items in `methodData` provided to `PaymentRequest` should throw
+ a `RangeError` according to step 4.3.3 of <https://www.w3.org/TR/payment-request/#constructor>.
+
+ The spec does mention in <https://www.w3.org/TR/payment-request/#conformance>
+ > User agents _MAY_ impose implementation-specific limits on otherwise unconstrained inputs,
+ > e.g., to prevent denial of service attacks, to guard against running out of memory, or to
+ > work around platform-specific limitations. When an input exceeds implementation-specific
+ > limit, the user agent _MUST_ throw, or, in the context of a promise, reject with, a
+ > `TypeError` optionally informing the developer of how a particular input exceeded an
+ > implementation-specific limit.
+ but does not specify whether this should happen before or after the above.
+
+ In WebKit's case, there is no "implementation-specific limit", so a `TypeError` should not
+ be thrown in either case.
+
+ * web-platform-tests/payment-request/payment-request-constructor-thcrash.https.html:
+ * web-platform-tests/payment-request/payment-request-constructor-thcrash.https-expected.txt:
+
2021-01-22 Youenn Fablet <[email protected]>
Add more descriptive messages to setLocalDescription/setRemoteDescription error cases
Modified: trunk/LayoutTests/imported/w3c/web-platform-tests/payment-request/payment-request-constructor-thcrash.https-expected.txt (271758 => 271759)
--- trunk/LayoutTests/imported/w3c/web-platform-tests/payment-request/payment-request-constructor-thcrash.https-expected.txt 2021-01-22 20:49:30 UTC (rev 271758)
+++ trunk/LayoutTests/imported/w3c/web-platform-tests/payment-request/payment-request-constructor-thcrash.https-expected.txt 2021-01-22 21:49:57 UTC (rev 271759)
@@ -1,5 +1,5 @@
-FAIL Don't crash if there is an abusive number of payment methods in the methodData sequence assert_equals: must be a TypeError expected "TypeError" but got "RangeError"
+PASS Don't crash if there is an abusive number of payment methods in the methodData sequence
PASS Don't crash if PaymentMethodData.supportedMethods is an abusive length
PASS Don't crash if the request id has an abusive length
PASS Don't crash if PaymentDetailsInit.total.label is an abusive length
Modified: trunk/LayoutTests/imported/w3c/web-platform-tests/payment-request/payment-request-constructor-thcrash.https.html (271758 => 271759)
--- trunk/LayoutTests/imported/w3c/web-platform-tests/payment-request/payment-request-constructor-thcrash.https.html 2021-01-22 20:49:30 UTC (rev 271758)
+++ trunk/LayoutTests/imported/w3c/web-platform-tests/payment-request/payment-request-constructor-thcrash.https.html 2021-01-22 21:49:57 UTC (rev 271759)
@@ -96,7 +96,7 @@
}
// Now, let's add an abusive amount of methods.
while (evilMethods.length < ABUSIVE_AMOUNT) {
- evilMethods = evilMethods.concat(evilMethods);
+ evilMethods.push({supportedMethods: "evil-method" + evilMethods.length});
}
try {
new PaymentRequest(evilMethods, defaultDetails);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
