Replace the implementation of maths in `UnsignedBigInteger`
and `SignedBigInteger` with LibTomMath. This gives benefits in terms of
less code to maintain, correctness and speed.
These changes also remove now-unsued methods and improve the error
propagation for functions allocating lots of memory. Additionally, the
new implementation is always trimmed and won't have dangling zeros when
exporting it.
An overlay port is required to add the `stdc-iec-559` and `install-pc`
patches.
The `stdc-iec-559` patch is required because Clang doesn't define
`__STDC_IEC_559__`. However, glibc and musl define it if `__GCC_IEC_559`
is not defined. The macro is taken from glibc source code.
The `install-pc` patch is required because libtommath doesn't install
the pkg-config files when building statically compromising our ability
to find it during build.
Clang: https://clang.llvm.org/c_status.html#:~:text=Yes-,
IEC%2060559%20support,-Unknown
glibc: https://sourceware.org/git/?p=glibc.git;a=blob;
f=include/stdc-predef.h
Having it as a method instead of a free function is necessary for the
next commits and generally allows for optimizations that require deeper
access into the `UnsignedBigInteger` / `SignedBigInteger`.
Also restrict the exponent to 32 bits to avoid huge memory allocations.
Having it as a method instead of a free function is necessary for the
next commits and generally allows for optimizations that require deeper
access into the `UnsignedBigInteger`.
The spec has a general rule for this, which is roughly that "If it's not
a falsey value, it's true". However, a couple of media-features are
always false, apparently breaking this rule. To handle that, we have an
array of false keywords in the JSON, instead of a single keyword. For
those always-false media-features, we can enter all their values into
this array.
Gets us 2 more WPT subtest passes.
Despite what the spec suggests, modern displays are not progressive, and
WPT expects `@media (scan: progressive)` to fail. So, return `none`
here to accurately represent that.
I've left a FIXME in case we can detect the display type from the OS
somehow in the future.
Gets us 4 WPT subtest passes.
Previously, for `foo < 30px` ranges, we'd flip them and store them as
`30px > foo` instead. That worked fine, but means the serialization is
wrong. So instead, keep them in their original form.
I experimented with giving Range two optional sub-structs instead of 4
optional members, thinking it would be smaller - but it's actually
larger, because the two Optional<Comparison>s fit snugly together. So,
the slightly-goofy all-Optionals remains.
This gets us 2 WPT passes that I'm aware of.
Instead of rejecting invalid media-feature values at parse time, we are
expected to parse them, and then treat them as Unknown when evaluating
their media query. To implement this, we first try to parse a valid
value as before. If that fails, or we have any trailing tokens that
could be part of a value, we then scoop up all the possible
ComponentValues and treat that as an "unknown"-type MediaFeatureValue.
This gets us 66 WPT passes.
Functionally this is the same before, as result is always True or False
before this point, and `True && Foo` evaluates to `Foo`. But this is
more clearly correct, instead of correct by coincidence.
This commit on its own has no observable behaviour changes, as we still
only return True or False, but for the next commit, we'll need to be
able to return the Unknown state here, and without this change we'd get
regressions.
This is very hacky and wrong, but it means there's one place to fix,
instead of one for UnresolvedStyleValue, and one for invalid
MediaFeatureValues which I'm about to implement.
The current spec defines this simply as `<ident>`, but does apparently
serialize as lowercase.
Because of this change, we no longer need to care about the deprecated
media types, as they all behave the same as unknown ones.
We still keep an enum around for KnownMediaType, to avoid repeated
string comparisons when evaluating it.
Gets us 2 WPT passes.
When restructuring a block node inside an inline parent, if the
nearest block ancestor is `display: inline-block`, ensure that
the generated anonymous wrappers also have `display: inline-block`.
This fixes layout issues with block elements nested
inside inline-block elements.
Previously floats would be placed next to the highest float that
fitted the new float on its line. However, this violates the rule
that floats should be placed under the preceding float if it does
not fit next to it.
This is functionaly the same since caller_context is the topmost
execution context on the stack, but makes it more clear that
we are directly inheriting the strict mode from the caller context
when pushing the next context on to the stack.
This test has flaked over the years, so let's add a screenshot test to
catch future regressions.
This copy of the test was taken from:
https://www.webstandards.org/files/acid2/test.html#top
Our CI infra does not support navigating to the "#top" anchor out of the
gate. So the intro section was removed from this copy so that we render
the happy face immediately.
We are required to delay the load event while any fetch is ongoing. We
currently have a very hacky re-fetch for images to go through the shared
resource request infrastructure. We must delay the load event during
this re-fetch.
This becomes an issue in an upcoming commit to import the acid2 test.
If we queue the <object> representation task multiple times in a row, we
would end up clearing the delayer after the first task completed. We
must continue delaying the load event until the last task completes.
This becomes an issue in an upcoming commit to import the acid2 test.
In a recent refactor of font styles, the new FontStyleStyleValue was
introduced; however, the `to_font_slope()` function was not changed to
understand this new type. When it tries to convert such a font style to
a keyword, it fails. We then rendered the wrong font-style.
When an element's ID is removed we only want to remove it from
`m_potentially_named_elements` if it is not also considered a
potentially named element due to it's name content attribute.
It is currently possible to hit this limit on pages with large numbers
of images. This temporary workaround prevents some WPT tests with large
numbers of images from failing.
