These interfaces are exposed on *, meaning it should work for workers
and our newly added shadow realm global object by being stored on the
universal global scope mixin.
This is required by mini Cloudflare invisible challenges, as it will
only run if the readyState is not "loading". If it is "loading", then
it waits for readystatechange to check that it's not "loading" anymore.
Initial about:blank iframes do not go through the full navigation and
thus don't go through HTMLParser::the_end, which sets the ready state
to something other than "loading". Therefore, the challenge would never
run, as readyState would never change.
Seen on https://discord.com/login
This includes a protocol for creating LibGC Heap allocated Swift
objects. Pay no attention to the Unmanaged shenanigans, they are
all behind the curtain.
This will allow us to use the GC to manage the lifetime of objects
that are not C++ objects, such as Swift objects. In the future we
could expand this cursed FFI to other languages as well.
CDATASection inherits from Text, and so it was incorrect for them to
claim not to be Text nodes.
This fixes at least two WPT subtests. :^)
It also exposed a bug in the DOM Parsing and Serialization spec,
where we're not told how to serialize CDATASection nodes.
Spec bug: https://github.com/w3c/DOM-Parsing/issues/38
Instead of checking the header in ZlibDecompressor::create(), we now
check it in read_some() when it is called for the first time. This
resolves a FIXME in the new DecompressionStream implementation.
Implemented by reusing AddMask display list item that was initially
added for `background-clip` property.
Progress on flashlight effect on https://null.com/games/athena-crisis
I believe this is an error in the UI Events spec, and it should be
updated to match the HTML spec (which uses WindowProxy everywhere).
This fixes a bunch of issues already covered by existing WPT tests.
Spec bug: https://github.com/w3c/uievents/issues/388
Note that WebKit has been using WindowProxy instead of Window in
UI Events IDL since 2018:
816158b4aa
TL;DR: There are two available sets of coefficients for the conversion
matrices from XYZ to sRGB. We switched from one set to the other, which
is what the WPT tests are expecting.
All RGB color spaces, like display-p3 or rec2020, are defined by their
three color chromacities and a white point. This is also the case for
the video color space Rec. 709, from which the sRGB color space is
derived. The sRGB specification is however a bit different.
In 1996, when formalizing the sRGB spec the authors published a draft
that is still available here [1]. In this document, they also provide
the matrix to convert from the XYZ color space to sRGB. This matrix can
be verified quite easily by using the usual math equations. But hold on,
here come the plot twist: at the time of publication, the spec contained
a different matrix than the one in the draft (the spec is obviously
behind a pay wall, but the numbers are also reported in this official
document [2]). This official matrix, is at a first glance simply a
wrongly rounded version of the one in the draft publication. It however
has some interesting properties: it can be inverted twice (so a
roundtrip) in 8 bits and not suffer from any errors from the
calculations.
So, we are here with two versions of the XYZ -> sRGB matrix, the one
from the spec, which is:
- better for computations in 8 bits,
- and official. This is the one that, by authority, we should use.
And a second version, that can be found in the draft, which:
- makes sense, as directly derived from the chromacities,
- is publicly available,
- and (thus?) used in most places.
The old coefficients were the one from the spec, this commit change them
for the one derived from the mathematical formulae. The Python script to
compute these values is available at the end of the commit description.
More details about this subject can be found here [3].
[1] https://www.w3.org/Graphics/Color/sRGB.html
[2] https://color.org/chardata/rgb/sRGB.pdf
[3] https://photosauce.net/blog/post/making-a-minimal-srgb-icc-profile-part-3-choose-your-colors-carefully
The Python script:
```python
# http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
from numpy.typing import NDArray
import numpy as np
### sRGB
# https://www.w3.org/TR/css-color-4/#predefined-sRGB
srgb_r_chromacity = np.array([0.640, 0.330])
srgb_g_chromacity = np.array([0.300, 0.600])
srgb_b_chromacity = np.array([0.150, 0.060])
##
## White points
white_point_d50 = np.array([0.345700, 0.358500])
white_point_d65 = np.array([0.312700, 0.329000])
#
r_chromacity = srgb_r_chromacity
g_chromacity = srgb_g_chromacity
b_chromacity = srgb_b_chromacity
white_point = white_point_d65
def tristmimulus_vector(chromacity: NDArray) -> NDArray:
return np.array([
chromacity[0] /chromacity[1],
1,
(1 - chromacity[0] - chromacity[1]) / chromacity[1]
])
tristmimulus_matrix = np.hstack((
tristmimulus_vector(r_chromacity).reshape(3, 1),
tristmimulus_vector(g_chromacity).reshape(3, 1),
tristmimulus_vector(b_chromacity).reshape(3, 1),
))
scaling_factors = (np.linalg.inv(tristmimulus_matrix) @
tristmimulus_vector(white_point))
M = tristmimulus_matrix * scaling_factors
np.set_printoptions(formatter={'float_kind':'{:.6f}'.format})
xyz_65_to_srgb = np.linalg.inv(M)
# http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
# Let's convert from D50 to D65 using the Bradford method.
m_a = np.array([
[0.8951000, 0.2664000, -0.1614000],
[-0.7502000, 1.7135000, 0.0367000],
[0.0389000, -0.0685000, 1.0296000]
])
cone_response_source = m_a @ tristmimulus_vector(white_point_d50)
cone_response_destination = m_a @ tristmimulus_vector(white_point_d65)
cone_response_ratio = cone_response_destination / cone_response_source
m = np.linalg.inv(m_a) @ np.diagflat(cone_response_ratio) @ m_a
D50_to_D65 = m
xyz_50_to_srgb = xyz_65_to_srgb @ D50_to_D65
print(xyz_50_to_srgb)
print(xyz_65_to_srgb)
```
fe46b2c141 added the reset-temp-inverse flag, but set it up so all
tempinverse ops were negated at the start of the next op; this commit
makes it so these flags actually persist for one op and not zero.
Fixes#2296.
We were previously throwing an exception if the generated code was
throwing an exception before it hit the implementation of the interface.
Instead, we are meant to catch any exception, and wrap that in a
rejected promise.
For example, this was impacting the fixed test in this commit as an
exception was being thrown when invoking WebIDL::convert_to_int<T>
as the given number was out of range, and the [EnforceRange]
extended attribute decorates that attribute.
This same type of case is seen for a few tests in WPT.
This change ensures that:
- if an element for which an accessible name otherwise wouldn’t be
computed is referenced in an aria-labelledby value, the accessible
name for the element will be computed as expected.
- if an element has both an aria-label value and also an
aria-labelledby value, the text from the aria-label value gets
included in the computation of the element’s accessible name.
Otherwise, without this change, some elements with aria-labelledby
values will unexpectedly end up without accessible names, and some
elements with aria-label values will unexpectedly not have that
aria-label value included in the element’s accessible name.
This color space is often used as a reference in WPT tests, having
support for it makes us pass 15 new tests:
- css/css-color/rec2020-001.html
- css/css-color/rec2020-002.html
- css/css-color/rec2020-003.html
- css/css-color/rec2020-004.html
- css/css-color/rec2020-005.html
- css/css-color/predefined-011.html
- css/css-color/predefined-012.html
That makes us pass the following WPT tests:
- css/css-color/prophoto-rgb-001.html
- css/css-color/prophoto-rgb-002.html
- css/css-color/prophoto-rgb-003.html
- css/css-color/prophoto-rgb-004.html
- css/css-color/prophoto-rgb-005.html
- css/css-color/predefined-009.html
- css/css-color/predefined-010.html
This color space is often used as a reference in WPT tests, having
support for it makes us pass 15 new tests:
- css/css-color/display-p3-001.html
- css/css-color/display-p3-002.html
- css/css-color/display-p3-003.html
- css/css-color/display-p3-004.html
- css/css-color/display-p3-005.html
- css/css-color/display-p3-006.html
- css/css-color/lab-008.html
- css/css-color/lch-008.html
- css/css-color/oklab-008.html
- css/css-color/oklch-008.html
- css/css-color/predefined-005.html
- css/css-color/predefined-006.html
- css/css-color/xyz-005.html
- css/css-color/xyz-d50-005.html
- css/css-color/xyz-d65-005.html
This makes us pass the following WPT tests:
- css/css-color/a98rgb-001.html
- css/css-color/a98rgb-002.html
- css/css-color/a98rgb-003.html
- css/css-color/a98rgb-004.html
- css/css-color/predefined-007.html
- css/css-color/predefined-008.html
In commit 1b82cb43c2 I accidentally
removed the paint transformation altogether. The result was that
zoomed-in SVGs, or SVG elements with a transformation applied could have
their gradient coordinates misplaced significantly.
This was also exposed in the `svg-text-effects` test by way of a slight
visual difference. Add a new test that very clearly exposes the fixed
issue by rotating the gradient coordinates by 45 degrees.
Before this change, a StringView with a character-data pointer would
never compare as equal to one with a null pointer, even if they were
both length 0. This could happen for example if one is
default-initialized, and the other is created as a substring.
That makes us pass the following WPT tests:
- css/css-color/srgb-linear-001.html
- css/css-color/srgb-linear-002.html
- css/css-color/srgb-linear-003.html
