| Age | Commit message (Collapse) | Author |
|---|
|
This allows us to be a bit closer to the spec phrasing and matches
what we do with WritableStream
|
|
The consume(size_t) overload consumes "at most" as many bytes as
requested, but consume() consumes exactly one byte.
This commit makes sure to avoid consuming past EOF.
Fixes #18324.
Fixes #18325.
|
|
This makes YouTube's thumbnails start appearing on the homepage.
Yes,seriously.
Simply put, this is because this check failed when Comment had the
incorrect prototype:
https://github.com/webcomponents/polyfills/blob/90cb97f847ce918289dac0978c50dcda0a0afd72/packages/shadycss/src/style-util.js#L397
This causes it to try and reconvert style sheets that are already in
Shady format, which would cause it to spuriously add things such as
class selectors on the end of tag selectors. This caused nothing to
match the selectors.
When YouTube is generating the thumbnails, it checks if the thumbnail
grid container has a non-zero clientWidth. If it's zero, it simply
bails generating thumbnails. Since the selectors for this container did
not apply, we would not properly create a paint box for it, causing
clientWidth to return zero.
|
|
Function `CellSyntaxHighlighter::rehighlight()` direct inserted spans
to TextDocument `m_span` vector missing out important reordering and
merging operation carried out by `TextDocument::set_spans()`.
This caused overlapping spans for a cell with only a `=` symbol
(one for the actual token and one for the highlighting) to
miscalculate `start` and `end` value and a `length` value (of
`size_t` type) with a `0-1` substraction (result: 18446744073709551615)
causing `Utf32View::substring_view()` to fail the
`!Checked<size_t>::addition_would_overflow(offset, length)` assertion
This remove the possibility to directly alter `TextDocument`'s spans
thus forcing the utilization of `HighlighterClient::do_set_spans()`
interface function.
Proper refactor have been applied to
`CellSyntaxHighlighter::rehighlight()` function
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This function interpolates the edges between the rectangle and another
rectangle based on a percentage value.
|
|
Every user of HTMLCollection does not expect the root node to be a
potential match, so let's avoid it by using non-inclusive sub-tree
traversal. This avoids matching the element that getElementsByTagName
was called on for example, which is required by Ruffle:
https://github.com/ruffle-rs/ruffle/blob/da689b7687d6bb23f37251e902ccddabdfcc5f48/web/packages/core/src/ruffle-object.ts#L321-L329
|
|
Log a FIXME on the debug log, along with a layout tree dump of the box
that we didn't expect to see. This will be annoying (until fixed),
but far less so than crashing the browser.
|
|
None of these are ever null after the VM has been initialized, as proved
by virtually every caller immediately dereferencing the raw pointer.
|
|
Some of these are allocated upon initialization of the intrinsics, and
some lazily, but in neither case the getters actually return a nullptr.
This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has
an `operator T&()`), and also has the interesting side effect of forcing
us to explicitly use the FunctionObject& overload of call(), as passing
a NonnullGCPtr is ambigous - it could implicitly be turned into a Value
_or_ a FunctionObject& (so we have to dereference manually).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VALUES-4 defines the internal representation of `calc()` as a tree of
calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal )
VALUES-3 lacked any definition here, so we had our own ad-hoc
implementation based around the spec grammar. This commit replaces that
with CalculationNodes representing each possible node in the tree.
There are no intended functional changes, though we do now support
nested calc() which previously did not work. For example:
`width: calc( 42 * calc(3 + 7) );`
I have added an example of this to our test page.
A couple of the layout tests that used `calc()` now return values that
are 0.5px different from before. There's no visual difference, so I
have updated the tests to use the new results.
|
|
This makes it possible to do arithmetic on them without having to
resolve to their canonical unit, which often requires context
information that is not available until the last minute. For example, a
Length cannot be resolved to px without knowing the font size, parent
element's size, etc.
Only Length currently requires such context, but treating all these
types the same means that code that manipulates them does not need to
know or care if a new unit gets added that does require contextual
information.
|
|
Level 4 drops the limitations of what types can be a denominator, which
means `<calc-number-sum>`, `<calc-number-product>` and
`<calc-number-value>` all go away.
|
|
I accidentally moved this when moving the CalculatedStyleValue methods,
and didn't notice because it was hidden in the middle. Oops!
|
|
This is not documented yet, but the preferred style is getting both
upfront instead of inlining various kinds of calls in places that use
the realm and vm.
|
|
|
|
|
|
This has the advantage of recognizing when the Stream reaches EOF and
avoids an endless loop.
|
|
|
|
Some even user-visible!
|
|
read_webp_first_chunk() sensibly assumes that if decode_webp_header()
succeeds, there are at least sizeof(WebPFileHeader) bytes available.
But if the file size in the header was less than the size of the header,
decode_webp_header() would truncate the data to less than that and
happily report success. Now it no longer does that.
Found by clusterfuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57843&sort=-opened&can=1&q=proj%3Aserenity
|
|
No behavior change.
(Well, technically mix() uses the other simple implementation of lerp
and the two have slightly different behavior if the arguments are of
very different magnitude and in various corner cases. But in practice,
for ICC profiles, it shouldn't matter. For a few profiles I tested, it
didn't have a measurable effect.)
|
|
|
|
|
|
PR #18166 introduced the ability to parse ECC certificates. If we
now fail here the reason is mostlikely something new and we should
prevent this rabbit hole from happening.
|
|
Some refactoring of our root ca loading process:
- Remove duplicate code
- Remove duplicate calls to `parse_root_ca`
- Load user imported certificates in Browser/RequestServer
|
|
|
|
StartingStateHandler and SeekingStateHandler were declaring their own
`bool m_playing` fields (from previous code where there was no base
class).
In the case of SeekingStateHandler, this only made the logging wrong.
For StartingStateHandler, however, this meant that it was not using
the boolean passed as a parameter to the constructor to define the
state that would be transitioned to after the Starting state finished.
This meant that when the Stopping state replaced itself with the
Starting state, playback would not resume when Starting state exits.
|
|
Otherwise, the Gfx::Painter will get choked up on NaNs and start
infinitely splitting paths till it OOMs.
|
|
|
