This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/26a4c4f
No behavioral change as we already did this correctly, but I changed
some implicit JS::Value creations to explicit ones.
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/983902e
We already had these defined as structs, but now they're properly
defined in the spec (opposed to the previous anonymous records), and we
don't have to make up our own names anymore :^)
Note that while we're usually not including 'record' in the name, in
this case the 'Duration Record' has a name clash with the Duration
object. Additionally, later editorial changes introduce CreateFooRecord
AOs, so let's just go with FooRecord structs here.
The blank string "" does not parse as JSON, and so the InspectorWidget
would fail to update the box-model information when inspecting elements
with no box, (for example, `<head>`) showing stale values instead. Now,
they show all 0s.
You could argue that InspectorWidget should be more resilient when given
invalid JSON strings, but making sure we only pass valid ones works
too.
This expands the InspectorWidget::Selection to include an optional
PseudoElement, which is then passed over IPC to request style
information for it.
As noted, this has some pretty big limitations because pseudo-elements
don't have DOM nodes:
- Declared style has to be recalculated when it's requested.
- We don't display the computed style.
- We don't display custom properties.
read_length in WebSocket::read_frame is used to track how many bytes we
have read in from the network. However, we was subtracting the number
of read in bytes instead of adding, underflowing it to about the 64-bit
unsigned integer limit.
This effectively limited us to only doing one read from the network.
This was only an issue if the server stalled when sending data,
which is especially common for large payloads. This would also cause us
to go out of sync. This meant when a new frame came in, we would read
the payload data of the previous frame as if it was the frame header
and payload of the next frame.
This allows us to read in the initial payload from Discord Gateway
that describes to the client the servers we are in, the emotes the
server has, the channels it has, etc. For an account that's only in
the Serenity Discord, this was about 20 KB (compressed!)
This resolves the ambiguity between whether a single number is a number
or a ratio. :^)
Also removed the "no more tokens" checks from
deea129b8c - that logic was completely
wrong, since there are always tokens after a value in the `(123 < foo <
456)` syntax.
These work differently from how we validate StyleValues. There, we parse
a StyleValue from the CSS, and then see if it is allowed in the
property. That causes problems when the syntax is ambiguous - for
example, `0` can be a number or a Length.
Here instead, we ask what kinds of value are allowed for a
media-feature, and then only attempt to parse those kinds of value.
This makes the ambiguity problem go away. :^)
Each media-feature in the spec only accepts one type of value, and/or
some identifiers. This makes the switch statements for the type a bit
excessive, but the spec does not *require* that only one type is
allowed, so this is more future-proof.
Previously, if you forgot to set a key on a SourceGenerator, you would
get this less-than-helpful error message:
> Generate_CSS_MediaFeatureID_cpp:
/home/sam/serenity/Meta/Lagom/../../AK/Optional.h:174: T
AK::Optional<T>::release_value() [with T = AK::String]: Assertion
`m_has_value' failed.
Now, it instead looks like this:
> No key named `name:titlecase` set on SourceGenerator
Generate_CSS_MediaFeatureID_cpp:
/home/sam/serenity/Meta/Lagom/../../AK/SourceGenerator.h:44:
AK::String AK::SourceGenerator::get(AK::StringView) const: Assertion
`false' failed.
