The spec assumes that we only store values against expanded longhands,
there are however limited circumstances where we store against
shorthands directly in addition to the expanded longhands. For example
if the value of the shorthand is unresolved we store an
UnresolvedStyleValue against the shorthand directly and a
PendingSubstitutionStyleValue against each of the longhands.
This commit updates the logic so that in the case we serialize a
shorthand directly we should also mark it's longhands as serialized to
avoid serializing them separately.
This also avoids the scenario where we tried to create and serialize a
ShorthandStyleValue with PendingSubstitutionStyleValue longhands, so we
can remove the check and related FIXME for that.
Fixes at least three WPT test that were previously timing out:
- html/semantics/embedded-content/media-elements/error-codes/error.html
- html/semantics/embedded-content/media-elements/location-of-the-media-resource/currentSrc.html
- html/semantics/embedded-content/the-video-element/video_crash_empty_src.html
We generated `PaintableFragment`s with a start and length represented in
UTF-8 byte offsets, but failed to consider that the offsets in a
`DOM::Range` are actually expressed in UTF-16 code units.
This is a bit of a mess: almost all web specs use UTF-16 code units as
the unit for indexing into text nodes, but we almost exclusively use
UTF-8 in our code base. Arguably the best thing would for us to use
UTF-16 everywhere as well: it prevents these mismatches in our
implementations for the price of a bit more memory usage - and even that
could potentially be optimized for.
But for now, try to do the correct thing and lazily allocate UTF-16 data
in a `PaintableFragment` whenever we need to index into it or if we're
asked to determine the code unit offset of a pixel position.
When clicking on a glyph or starting a selection on it, we would use the
glyph's offset/index as the position which represents the left side of
the glyph, or the position between the glyph and the glyph before it.
Instead of looking at which glyph is under the mouse pointer, look at
which glyph boundary is closer. Now, if you click to the right of a
glyph (but still on that glyph), it correctly selects the next glyph's
offset as the position.
The text track processing model would previously spin forever waiting
for the track URL to change. It would then recursively invoke itself
to handle the new URL, again entering the spin loop. This meant that
tracks could easily cause event loop hangs.
We now have an observer system to be notified when the track state
changes instead. This lets us exit the processing model and move on.
The "longhands" array is populated in the code generator to avoid the
overhead of manually maintaining the list in Properties.json
There is one subtest that still fails in
'cssstyledeclaration-csstext-all-shorthand', this is related to
us not maintaining the relative order of CSS declarations for custom vs
non-custom properties.
url() has some limitations because of allowing unquoted URLs as its
contents. For example, it can't use `var()`. To get around this, there's
an alternative `src()` function which behaves the same as `url()` except
that it is parsed as a regular function, which makes `var()` and friends
work properly.
There's no WPT test for this as far as I can tell, so I added our own.
Some instances of CSSStyleProperties can lack an owner node, for
instance the return value of a call to `window.getComputedStyle` where
the specified pseudo-element is invalid. In this case we should treat
the computed style as empty, as there is no node to compute the style
for.
Previously we would just throw it away and construct a new (empty) one
when required. This doesn't work as any existing references to the old
instance will contain out of date information. Now we retain and update
the existing instance instead.
Resolves a FIXME in `CSSRuleList::insert_a_css_rule`. Gets us a bit
closer to passing https://wpt.live/css/cssom/at-namespace.html but that
requires more work around parsing of selectors with namespaces (namely
disallowing use of undeclared selectors), which I have added a FIXME
for.
The spec requires us to store properties in their shorthand-expanded
form and in the "specified" order, removing duplicates prefering based
on "cascading order". We already enforced this in `set_property` but
not at creation time (e.g. in stylesheets) or in `set_css_text` (e.g.
updating style attribute).
This commit enforces the spec requirements at all the relevant points.
We no longer include logical properties in the return value of
`getComputedStyle` as they are mapped to their physical equivalents in
`StyleComputer::for_each_property_expanding_shorthands`, but resolving
that requires a relatively large rework of how we handle logical
properties, (namely moving when we map them to their physical
equivalents from parse time to style computation time).
This also exposes two false positive tests in
wpt-import/css/cssom/border-shorthand-serialization.html related to us
not yet supporting the border-image css property.
Based very scientifically on what's listed here:
https://harfbuzz.github.io/what-does-harfbuzz-do.html
I've moved the code into LibGfx because including a HarfBuzz header
directly from LibWeb is a little unpleasant. But the Gfx::FontTech enum
follows the CSS definitions for font features for simplicity.
TrueType collections are supported. SVG and Embedded OpenType are not,
but they're not widely supported by other browsers so that's fine.
Most of the features are completely supported by HarfBuzz, so we can
just return true. Graphite support is optional (and it appears we use a
build of HarfBuzz without it) but there's a define we can check.
Incremental Font Transfer is a whole separate thing that we definitely
don't support yet.
