Our own Inspector differs from most other DevTools implementations with
regard to highlighting DOM nodes as you hover elements in the inspected
DOM tree. In other implementations, as you change the hovered node, the
browser will render a box model overlay onto the page for that node. We
currently don't do this; we wait until you click the node, at which
point we both paint the overlay and inspect the node's properties.
This patch does not change that behavior, but separates the IPCs and
internal tracking of inspected nodes to support the standard DevTools
behavior. So the DOM document now stores an inspected node and a
highlighted node. The former is used for features such as "$0" in the
JavaScript console, and the latter is used for the box model overlay.
Our Inspector continues to set these to the same node.
This reduces the number of `.cpp` files that need to be recompiled when
one of the below header files changes as follows:
CSS/ComputedProperties.h: 1113 -> 49
CSS/ComputedValues.h: 1120 -> 209
This reduces the number of `.cpp` files that need to be recompiled when
one of the below header files changes as follows:
Painting/Command.h: 1030 -> 61
Painting/DisplayList.h: 1030 -> 60
Painting/DisplayListRecorder.h: 557 -> 59
We've long claimed to support this, but then silently ignored string
values, until 4cb2063577 which would
not-so-silently crash instead. (Oops)
So, actually pass the string value along and use it in the list marker.
As part of this, rename our `list-style-type` enum to
`counter-style-name-keyword`. This is an awkward name, attempting to be
spec-based. (The spec says `<counter-style>`, which is either a
`<counter-style-name>` or a function, and the `<counter-style-name>` is
a `<custom-ident>` that also has a few predefined values. So this is the
best I could come up with.)
Unfortunately only one WPT test for this passes - the others fail
because we produce a different layout when text is in `::before` than
when it's in `::marker`, and similar issues.
The Web::CSS::Parser's GradientParsing ignores color-stops if
it is only a single one. This change allows to have color-stops
with double positions against a single color.
Further, also allows for `linear-gradient(black)` and similar
other gradient functions
Allow wheel event to be consumed by a `overflow: scroll` box only if it
has content that overflows a scrollport.
This fixes the timing issue in the
`Text/input/scroll-window-using-wheel-event.html` test, where a `<body>`
element with `overflow: scroll` was incorrectly consuming wheel events
that should have propagated to the window.
Previous name for misleading because it checks if box could be scrolled
by user input event which is diffent from checking if box is scrollable.
For example box with `overflow: hidden` is scrollable but it can't be
scrolled by user input event.
To be properly compatible with calc(), the resolved() methods all need:
- A length resolution context
- To return an Optional, as the calculation might not be resolvable
A bonus of this is that we can get rid of the overloads of `resolved()`
as they now all behave the same way.
A downside is a scattering of `value_or()` wherever these are used. It
might be the case that all unresolvable calculations have been rejected
before this point, but I'm not confident, and so I'll leave it like
this for now.
My previous attempt at resolving the continuation chain tried to deal
with `pointer-events: none` by repeatedly falling back to the parent
paintable until one was found that _would_ want to handle pointer
events. But since we were no longer performing hit-tests on those
paintables, false positives could pop up. This could happen for
out-of-flow block elements that did not overlap with their parent rects,
for example.
This approach works much better since it only handles the continuation
case that's relevant (the "middle" anonymous box) and it does so during
hit-testing instead of after, allowing all the other relevant logic to
come into play.
Instead of ignoring any paintable immediately when they're invisible to
hit-testing, consider every candidate and while the most specific
candidate is invisible to hit-testing, traverse up to its parent
paintable.
This more closely reflects the behavior expected when wrapping block
elements inside inline elements, where although the block element might
have `pointer-events: none`, it still becomes part of the hit-test body
of the inline parent.
This makes the following link work as expected:
<a href="https://ladybird.org">
<div style="pointer-events: none">Ladybird</div>
</a>
Our layout tree requires that all containers either have inline or
non-inline children. In order to support the layout of non-inline
elements inside inline elements, we need to do a bit of tree
restructuring. It effectively simulates temporarily closing all inline
nodes, appending the block element, and resumes appending to the last
open inline node.
The acid1.txt expectation needed to be updated to reflect the fact that
we now hoist its <p> elements out of the inline <form> they were in.
Visually, the before and after situations for acid1.html are identical.
The existing `::unite_horizontally()` and `::unite_vertically()` tests
did not properly test the edge cases where left/top in the Rect were
updated, so they get re-arranged a bit.
Previously most of the calculations for `object-fit` and
`object-position` were based on device pixels, meaning that images would
render differently based on zoom and DPI settings. Instead those
calculations now use css pixels and only the final draw-call is based
on device-pixels.
SVGs are rendered with subpixel precision. As such it can happen that
paths are rendered with less than 1px width or height and that they can
have a bounding box thinner than 1px. Due to an optimization such paths
were ignored when painting because their bounding box was incorrectly
calculated to be empty.
As a result horizontal or vertical lines inside SVGs were missing if:
* The SVG is displayed at viewbox size but the lines are defined with
less than 1px.
* The SVG contians 1px-thin lines, but is displayed at a size smaller
than viewbox size.
To prevent this, the bounding box of the path is now enlarged to contain
all pixels that are partially affected.
In particular:
- Don't compute DOM node editability if we don't need it. This was 22%
of CPU time when scrolling on Wikipedia.
- Defer inversion of transformed coordinates until we actually need
them, after we've performed early returns.
Previously, the`HTMLInputElement.selectinStart` and
`HTMLInputElement.selectionEnd` IDL setters, and the
`setRangeText()` IDL method were used when updating an input's value
on keyboard input. These methods can't be used for this purpose,
since selection doesn't apply to email type inputs. Therefore, this
change introduces internal-use only methods that don't check whether
selection applies to the given input.
This improves the quality of our font rendering, especially when
animations are involved. Relevant changes:
* Skia fonts have their subpixel flag set, which means that individual
glyphs are rendered at subpixel offsets causing glyph runs as a
whole to look better.
* Fragment offsets are no longer rounded to whole device pixels, and
instead the floating point offset is kept. This allows us to pass
through the floating point baseline position all the way to the Skia
calls, which already expected that to be a float position.
The `scrollable-contains-table.html` ref test needed different table
headings since they would slightly inflate the column size in the test
file, but not the reference.
By doing that we eliminate the need for the vertical flip flag.
As a side effect it fixes the bug when doing:
`canvasContext2d.drawImage(canvasWithWebGLContext, 0, 0);`
produced a flipped image because we didn't account for different origin
while serializing PaintingSurface into Gfx::Bitmap.
Visual progress on https://ciechanow.ski/curves-and-surfaces/
CSS filters work similarly to canvas filters, so it makes sense to have
Gfx::Filter that can be used by both libraries in an analogous way
as Gfx::Color.
The DOM spec defines what it means for an element to be an "editing
host", and the Editing spec does the same for the "editable" concept.
Replace our `Node::is_editable()` implementation with these
spec-compliant algorithms.
An editing host is an element that has the properties to make its
contents effectively editable. Editable elements are descendants of an
editing host. Concepts like the inheritable contenteditable attribute
are propagated through the editable algorithm.
Most computed border-radii contain their initial values, and since the
normalized initial border radii are always zero, there is no need to do
expensive floating point math to normalize them.
OpenGL's origin is at the bottom-left corner, while Skia's origin is at
the top-left corner. This change adds a transformation to compensate for
this difference when rendering PaintingSurface attached to WebGL
context.
restore() corresponding to ApplyFilters should be called after stacking
context content is painted, not before.
Fixes regression introduced in c94b4316e7
