This avoids doing pointless plotting for scanlines that will never be
seen.
Note: This currently can only clip edges vertically. Horizontal clipping
is more tricky, since edges that are not visible can still change how
things accumulate across the scanline.
Fixes#22382
Sadly, this causes a bunch of LibWeb test churn as this change
imperceptibly changes the final rasterized output.
If a short string is used for the attribute value, then the result of:
```cpp
auto const view = element.attribute(attribute_name).value_or({})
.bytes_as_string_view().split_view(' ');
```
is an array of string views pointing into a temporarily allocated
string.
With this change we keep string on stack until the end of scope.
Page that allows to reproduce the problem.
```html
<!DOCTYPE html><style>
div[data-info~="a"] {
background-color: yellow;
}
</style><div data-info="a">a</div>
```
This was a normative change in the Array.fromAsync spec which we already
implemented :^). See:
https://github.com/tc39/proposal-array-from-async/commit/689d0d
I've left an existing FIXME in there for some other bug which we have
which is causing some test262 test cases to fail.
It's not safe to access m_document here since GC may have deleted it
by the time we're being deleted. Instead, move this to a finalize()
override, since those are guaranteed to be called while both objects
are still alive.
Due to a `requires` mistake, we were always using the fallback
size-based cell allocators.
Also, now that we start using them, make them NeverDestroyed so
we don't try to deallocate them on program exit.
Instead of making the "Entry" inner struct GC-allocated and marking
*that*, we now mark the image instead.
This fixes an issue found by ASAN on https://mozilla.com/
This allows us to reject invalid images before trying to decode them.
The spec requires more tag to be present[1] but as we don't use them for
decoding I don't see the point.
[1] - XResolution, YResolution and ResolutionUnit
We would previously not return a RadioNodeList in the curious case where
a named item resolves to two different elements within the form.
This was not a problem when calling namedItem directly in the IDL as
named_item_or_radio_node_list shadows named_item but is exposed when
calling the property through array bracket notation (as an example).
Fix this, and add a bunch more tests to cover
HTMLFormControlsCollection.
This allows us to improve the const-correctness in RadioNodeList, which
has been made possible as of: 5f0ccfb499 now that a GC-visit accepts a
const GC pointer.
With this change "display: contents" ancestors are not considered as
insertion point for inline nodes similar to how we already ignore them
for non-inline nodes.
Fixes https://github.com/SerenityOS/serenity/issues/22396
TIFF images with the PhotometricInterpretation tag set to RGBPalette are
based on indexed colors instead of explicitly describing the color for
each pixel. Let's add support for them.
The test case was generated with GIMP using the Indexed image mode after
adding an alpha layer. Not all decoders are able to open this image, but
GIMP can.
We were previously assuming that the input offsets and lengths were all
in raw byte offsets into a UTF-8 string. While internally our String
representation may be in UTF-8 from the external world it is seen as
UTF-16, with code unit offsets passed through, and used as the returned
length.
Beforehand, the included test included in this commit would crash
ladybird (and otherwise return wrong values).
The implementation here is very inefficient, I am sure there is a
much smarter way to write it so that we would not need a conversion
from UTF-8 to a UTF-16 string (and then back again).
Fixes: #20971
In a bunch of cases, this actually ends up simplifying the code as
to_number will handle something such as:
```
Optional<I> opt;
if constexpr (IsSigned<I>)
opt = view.to_int<I>();
else
opt = view.to_uint<I>();
```
For us.
The main goal here however is to have a single generic number conversion
API between all of the String classes.
With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
While it would be more hygienic to get a fresh Navigable each time,
loading `about:blank` still means we discard the current Document.
This does noticeably increase the duration of running the LibWeb test
suite. On my machine, we go from ~5.5 seconds to ~7.7.
Calling test() multiple times in the same test file is not actually
valid, and can cause the following test to hang forever. So let's stop
doing that in the one test that did so, and also prevent the same
mistake happening again. :^)
Throwing an exception on subsequent test() calls means that we don't
hang, the test will fail with missing output, and we get a log message
explaining why.
This caused a dangling reference down the line, which lead to funny
things like the following:
> cd Bui[tab]
> cd Bui^@^@
By returning a direct reference to the suggestion in question, we can be
sure that the referenced object is alive until the next suggestion
cycle.
Half the functions used are not readily available on windows, instead of
creating more ifdef soup, this commit simply disables the rich debug
stuff on windows.
Our existing AnonymousVMObject cloning flow contains an optimization
wherein purgeable VMObjects which are marked volatile during the clone
are created as a new zero-filled VMObject (as if it was purged), which
lets us skip the expensive COW process.
Unfortunately, one crucial part was missing: Marking the cloned region
as purged, (which is the value returned from madvise when unmarking the
region as volatile) so the userland logic was left unaware of the
effective zero-ing of their memory region, resulting in odd behaviour
and crashes in places like our malloc's large allocation support.
This is a pretty straightforward test, but I managed to make this crash
on real sites while trying to fix#20971 without any other test in the
existing suite failing.
