If a DOM node is an element with pseudo-elements, but it has no child
DOM nodes and is not a shadow host, then the code that serializes its
pseudo-elements would get skipped, making them not show up in the
inspector.
Right now, we deviate from the CSSOM spec regarding our
CSSStyleDeclaration classes, so this is not as close to the spec as I'd
like. But it works, which means we'll be able to test pseudo-element
styling a lot more easily. :^)
As noted, this is hacky because the parser wasn't written to allow
parsing an individual component of a selector. (Fox example, the
convenient-sounding `parse_pseudo_simple_selector()` assumes the first
colon has already been consumed...) So until that changes, this parses
the input as an entire selector-list, and then throws it away if it's
not a single pseudo-element selector.
It's only temporary though, I promise. 😅
Instead of carrying the display list for a mask in each command that
might potentially be affected by "background-clip: text", this change
introduces a new AddMask command that is applied once for all
background layers within one box.
The new AddMask command includes a rectangle for the mask destination
that is translated by the corresponding scroll offset.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/857
The spec didn't match how other browsers behave, and we dutifully did
what the spec said. A spec bug has been filed, so let's fix this locally
for now with a FIXME.
add_clip_rect() accepts a rectangle in viewport-relative coordinates,
so it must be translated by the enclosing scroll offset to be displayed
correctly inside a scrollable box.
This change fixes layering violation by moving to_px() calls to happen
before display list recording. Also it should make display list
recording a bit faster by resolving background properties beforehand.
I previously believed there was no way a detached document should have
layout information, but it turns out there is a way: getComputedStyle().
So we need to account for cases where we have a layout node, but no
navigable, since that is a state we can get into at this moment.
Fixes#354
For the SVG <use> element, we want to support loading HTML documents
that have a SVG element inside of it pointed to by the URL fragment.
In this situation we would need to fetch and parse the entire document
in SharedImageRequest (so that we can still cache the SVGs). Rename
SharedImageRequest to SharedResourceRequest to make the class a little
more generic for future usecases.
This closer mirrors handle_failed_fetch, making the handling slightly
more clear to understand. It also means that we don't need to take a
strong reference to this on a successful SVG resource load.
...When loading images through SharedImageRequest.
There is a small behavioural difference here - handle_failed_fetch
clears the pending callbacks whereas handled_failed_decode was
previously not. This does not seem intentional, and appears like a bug.
Implementing it this way is _slightly_ simpler - and also means we
don't need to take a strong handle to this in the case of loading an
SVG image.
Web specs do not return through javascript percent decoded URL path
components - but we were doing this in a number of places due to the
default behaviour of URL::serialize_path.
Since percent encoded URL paths may not contain valid UTF-8 - this was
resulting in us crashing in these places.
For example - on an HTMLAnchorElement when retrieving the pathname for
the URL of:
http://ladybird.org/foo%C2%91%91
To fix this make the URL class only return the percent encoded
serialized path, matching the URL spec. When the decoded path is
required instead explicitly call URL::percent_decode.
This fixes a crash running WPT URL tests for the anchor element on:
https://wpt.live/url/a-element.html
Previously, calling `setProperty` or `removeProperty` from JS on a
CSSStyleDeclaration returned from `getComputedStyle()` would return
null. We now return a NoModificationAllowedError instead, which aligns
our implementation with the specification.
This also fixes a bug where task IDs were being deallocated from the
wrong IDAllocator. I don't know if it was actually possible to cause any
real trouble with that mistake, nor do I know how to write a test for
it, but this makes the bug go away.
Not every value in a StyleProperties will be non-null by the time we
perform `revert`, so let's make a specialized function for reverting a
property instead of using the path that requires the value to be
non-null.
The "text-overflow" property affects text that may get clipped if it is
larger than its container and does not do any line breaks.
The ellipsis character gets added to the end and the rest of the text
gets trunctated if the property is set to "ellipsis".
This patch implements this behavior in the InlineFormattingContext. :^)
The "text-overflow" property is also added to the
getComputedStyle-print-all test.
