Age | Commit message (Collapse) | Author |
|
The files weren't starting exactly from the beginning before.
This happened because the parameter now takes the sample index, instead
of a seekpoint.
|
|
Out of 40/63 failed tests, this change reduces the number down to four.
:^)
See: #14683
|
|
* A border-radius + a border on a <img> tag
- The border-radius on the <img> should shrink to line up with
the border.
* A border-radius + a border on a div with overflow: hidden
- The clipping border-radius should shrink (same as the image).
|
|
This fixes the shape of the subreddit logo on new reddit.
|
|
|
|
|
|
|
|
This pulls process_blob_parts() out of the Blob class and makes it
publicly accessible.
|
|
Blob::bytes() returns the ReadonlyBytes representation of our internal
ByteBuffer.
This change requires us to ByteBuffer::copy() Blob's ReadonlyBytes to a
ByteBuffer in XHR::send() and corresponding error handling of the copy
operation.
This removes the need for Blob to declare XMLHttpRequest as a friend
class.
|
|
This is a normative change to the Intl NumberFormat V3 spec:
https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
|
|
This is a normative change to the Intl NumberFormat V3 spec:
https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
|
|
This is a normative change to the Intl spec:
https://github.com/tc39/ecma402/commit/769df4b
|
|
|
|
That this did not already happen took me by surprise, as for
most other similar containers/types in AK (e.g. Span) the index
will be checked. This check not happening could easily let
off-by-one indexing errors slip through the cracks.
|
|
Previously we were checking if values were "auto" after resolving the
"auto"-ness out of them, which didn't work. There's still a bunch of
work to do on this algorithm, but now we can at least resolve some basic
automatic height scenarios.
|
|
We already cache these values with each flex item, so let's just use
those instead.
|
|
We'll eventually need some way to determine if a calc() value results
in a definite size.
|
|
Percentage sizes of flex items are relative to the flex container, but
even when the flex container is automatically sized, we still have to
support them.
To make this work, we first do a pass where percentage sizes are ignored
(treated as "auto", basically) in order to get a "reference" value.
Then we do a second pass where percentages can be resolved against this
reference value.
|
|
Follow the spec more closely.
|
|
We were neglecting to clamp flex items when calculating the intrinsic
main size of the flex container. This was covered by a FIXME, which we
can now remove. :^)
|
|
We had an older incomplete implementation of flex container max-content
sizing that we used for unconstrained main size determination.
This patch replaces the old implementation with a call to the new
max-content sizing code.
Note that this isn't a complete implementation of flex container sizing
still, but at least we've deduplicated some code.
|
|
|
|
|
|
The CSS-FLEXBOX-1 spec gives us two situations in which flex item cross
sizes should be considered definite. Both of them happen *during* flex
layout, which is super finicky but it is what it is.
|
|
When calculating intrinsic sizes, we don't need to recurse into *every*
box and layout its insides. IIUC, we can skip any unconstrained box with
definite sizes in both axes. So this patch does exactly that.
|
|
This matches the exact terminology used in CSS-SIZING-3:
https://drafts.csswg.org/css-sizing-3/#intrinsic-sizing
|
|
Also avoid calculating both min-content and max-content sizes when only
one of them is needed.
|
|
Percentage values for `min-height` and `max-height` should be resolved
against the containing block height, not its width.
|
|
When we decide that a box has definite width or height based on its
containing block's corresponding size, we'll want to resolve the
current box's size as well. Otherwise anyone querying the size on
this box will get the bogus message of "yes, this definite, and its
value is zero."
|
|
Previously, we considered all LengthPercentage values for used flex
basis to be definite. This is not accurate, as percentages should only
be considered definite if the reference value they resolve against is
a definite size.
Fix this by checking the flex container's main definite size flag.
|
|
There's no need to override the sizes before calculating the cross size.
Besides, by the time we're calculating the hypothetical cross size of
flex items, we may already have established a definite main size anyway,
so overriding it would be wrong.
|
|
This patch implements two of the special "definite size" rules from
the CSS-FLEXBOX-1 spec.
https://drafts.csswg.org/css-flexbox-1/#definite-sizes
|
|
From CSS-SIZING-3:
"...the size of the containing block of an absolutely positioned element
is always definite with respect to that element."
|
|
This state is less static than we originally assumed, and there are
special formatting context-specific rules that say certain sizes are
definite in special circumstances.
To be able to support this, we move the has-definite-size flags from
the layout node to the UsedValues struct instead.
|
|
|
|
|
|
|
|
Absolutely positioned boxes are handled by the BFC destructor, so we
need to make sure the ICB BFC is destroyed if we want these boxes
to get laid out.
|
|
Note that we cannot use CompareTypedArrayElements until the change-
array-by-copy proposal picks up the change to no longer throw with
detached array buffers.
|
|
By aligning Array.prototype.sort with the spec, this removes the direct
invocation of CompareArrayElements from array_merge_sort. This opens the
door for TypedArray to use SortIndexedProperties as well because now
array_merge_sort does not assume what kind of array it is invoked with.
Further, this addresses a FIXME to avoid an extra JS heap allocation.
|
|
This isn't actually much of an issue because if the LHS side value is -0
and the RHS value is +0, errantly returning 0 in the comparison function
here has the same effect as correctly returning -1. In both cases, the
-0 is left on the LHS.
|
|
|
|
|
|
|
|
InterruptController's model incorrectly returned a char[] instead
of a StringView.
|
|
Remove the static PNG bitmaps we've been using for GUI radio buttons
and replace them with on-the-fly pixel painting.
This fixes a long-standing issue where radio buttons always looked the
same, regardless of system theme settings. :^)
|
|
|
|
|
|
|
|
The only remaining "manual" knob instatiation is the octave, which will
be moved into an entirely different UI in the future.
|