This creates a bitmap filled with a fixed color, then (in memory)
saves it as jpeg and loads it again, and repeats that until the
color of the bitmap no longer changes. It then reports how many
iterations that took, and what the final color was.
It does this for a couple of colors.
This is for quality assessment of the jpeg codec. Ideally, it should
converge quickly (in one iteration), and on a color not very far from
the original input color.
This is the same fix as 07928129dd
also applied to the SVG script element case. Fixes a crash for the
following HTML:
```html
<svg>
<script>
location.reload();
</script>
</svg>
```
As with the linked commit:
> With this change WebContent does not crash when `location.reload()` is
> invoked but `Navigable::reload()` still not working because of spec
> issue (whatwg/html#9869) so we can't add a
> test yet.
HTML fragments are parsed with a temporary HTML document that never has
its flag set to say that it is ready to have scripts executed. For these
fragments, in the HTMLParser, these scripts are prepared, but
execute_script is never called on them.
This results in the HTMLParser waiting forever on the document to be
ready to have scripts executed.
To fix this, only wait for the document to be ready if we are definitely
going to execute a script.
This fixes a hang processing the HTML in the attached test, as seen on:
https://github.com/SerenityOS/serenityFixes: #22735
Previously, constructing a `UnsignedBigInteger::from_base()` could
produce an incorrect result if the input string contained a valid
Base36 digit that was out of range of the given base. The same method
would also crash if the input string contained an invalid Base36 digit.
An error is now returned in both these cases.
Constructing a BigFraction from string is now also fallible, so that we
can handle the case where we are given an input string with invalid
digits.
This utility uses the Core::DirIterator facility which in turn uses the
get_dir_entries syscall. Therefore, this utility lets us to view the
actual values for inode numbers, and entry type value for directory
entries.
This will be useful in the upcoming listdir utility (in the next commit)
to get the file type which is obtained in the get_dir_entries syscall,
so it's not changed later by the fstatat syscall.
This will ensure that we get the raw file type value as it's represented
by directory entries from the get_dir_entries syscall.
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
The paintable tree structure more closely matches the painting order
when fragments are owned by corresponding inline paintables. This
change does not affect the layout tree, as it is more convenient for
layout purposes to have all fragments owned by a block container in
one place.
Additionally, this improves performance significantly on pages with
many fragments, as we no longer have to walk the ancestor chain up
to the closest block container to determine if a fragment belongs
to an inline paintable.
Instead of trying to be clever and detaching the paint tree lazily,
just detach all paintables from both DOM and layout tree when building
and committing respectively.
Switch over from deprecated_attribute to attribute, and reuse the result
of this lookup for both checking whether that attribute exists - and for
retrieving the value of that attribute when we need it.
Rather than resolving the text-shadow each time painting commands are
recorded, we can resolve it once during the layout commit and save the
resolved values in paintable fragments. This is also step towards
getting rid of layout node pointer in paintable fragment.
If the entire document is invalidated, we know a full style update is
coming soon, and there's no need to try and invalidate a smaller part.
This avoids a *lot* of work on some pages. As an example, we are able to
skip ~1.5 million style invalidations on https://html.spec.whatwg.org/
This is a part of refactoring towards making the paintable tree
independent of the layout tree. Now, instead of transferring text
fragments from the layout tree to the paintable tree during the layout
commit phase, we allocate separate PaintableFragments that contain only
the information necessary for painting. Doing this also allows us to
get rid LineBoxes, as they are used only during layout.
Use the [FlyString] extended attribute to allow these functions to take
an Optional<FlyString> directly, allowing us to tidy up some conversions
from Optional<String>.
`JsonValue::to_byte_string` has peculiar type-erasure semantics which is
not usually intended. Unfortunately, it also has a very stereotypical
name which does not warn about unexpected behavior. So let's prefix it
with `deprecated_` to make new code use `as_string` if it just wants to
get string value or `serialized<StringBuilder>` if it needs to do proper
serialization.
`on_game_start` is not called until the player makes a move, so waiting
until then means that the solve button would still be visible when
starting a new game after completing one. By hiding the button in
`on_game_end`, this happens when the game-over animation starts playing
instead.
