The gist is that we need to construct an ICU date-time formatter for
each possible Temporal type. This is of course going to be expensive.
So instead, we construct the configurations needed for the ICU objects
in the Intl.DateTimeFormat constructor, and defer creating the actual
ICU objects until they are needed.
Each formatting prototype can also now accept either a number (as they
already did), or any of the supported Temporal objects. These types may
not be mixed, and their properties (namely, their calendar) must align
with the Intl.DateTimeFormat object.
Attempting to set `HTMLInputElement.size` to 0 via IDL now throws an
IndexSizeError DOMException. Attempting to set it to a value larger
than 2147483647 results in it being set to the default value.
I dug through the code and the WebCryptoAPI spec to figure out the
reason for `... mixed case parameters` WPT tests and figured out that
our implementation was slightly wrong.
By being closer to the spec we can now pass those tests and also remove
a bunch of duplicated code.
Context: https://github.com/LadybirdBrowser/ladybird/pull/2598#discussion_r1859263798
To check whether a NavigationParams is null, we have to check whether
it's `Empty` or `NullWithError`. Instead, we can merge both of these
possible variants into an optional error. If `NullOrError` has no
value it's null, otherwise it contains an error message.
While the code that did this referred to the HTML spec, other browsers
appear not to have this behavior when parsing XML, and it breaks a WPT
subtest.
This change does not appear to break any tests, and fixes 1 WPT subtest.
Size negotiation should not occur for other viewports, such as iframe,
since that would allow content inside the iframe to affect the size of
the iframe in the containing document.
300 new subtest passes on WPT. :^)
If `HTMLMarqueeElemnt.scrollAmount` or `HTMLMarqueeElemnt.scrollDelay`
is set to a value larger than 2147483647, then it should be set to its
default value.
Previously, `ECDH::generate_key` was implemented by storing a
`ByteBuffer` in the `InternalKeyData`. This improves the implementation
by using internal structures of already-parsed data.
Parse and store the `ECPrivateKey` extracted from the
`privateKeyAlgorithm` field of the ASN.1 `PrivateKeyInfo` sequence when
the algorithm identifier is `ec_public_key_encryption`.
The parsing function returns `ErrorOr` instead of an "empty" key, like
`parse_rsa_key` does. To me, this seemed better in terms of reliability.
As mentioned in the previous commit, there is room for improvement.
Added basic EC private and public key definitions as well as ASN.1
encoding and decoding.
A lot of refactoring can be made around the ASN.1 processing (here and
in other parts of the codebase) by utilizing what is available
in `LibCrypto::Certificate` as macros, but I think it's outside the
scope of implementing ECDH support for WebCryptoAPI.
It looks like the `SECPxxxr1` was made mainly to work with the TLS
implementation which requires everything to be bytes. This is not always
the case and a loss of generality.
I have added some methods that take and return `UnsignedBigInteger`s
for better interoperability with ASN.1 stuff. I would like to remove
the old methods relying on bytes, but I haven't made my mind around how
to generalize it for all curves.
Add support for encoding parameters in `wrap_in_private_key_info` and
`wrap_in_subject_public_key_info` as well as turn `Span<int>` into
`Span<int const>`.
If we were able to parse an ISO8601 Date string, but the parse results
in an invalid date (e.g. out of the min/max range), we should abort
parsing immediately.
