This is "update document for history step application" but that's too
long for the commit title. :^)
No code changes, just adding more FIXME comments for the new steps.
(And indented step 7's substeps for clarity.)
Corresponds to https://github.com/whatwg/html/pull/10910
Before this change, `m_needs_repaint` was reset in
`Document::record_display_list()` only when the cached display list was
absent. This meant that if the last triggered repaint used the cached
display list, we would keep repainting indefinitely until the display
list was invalidated (We schedule a task that checks if repainting is
required 60/s).
This change also moves `m_needs_repaint` from Document to
TraversableNavigable as we only ever need to repaint a document that
belongs to traversable.
We just need to create the backend context once and let Skia handle the
context's state.
On my machine, this reduces the load time for https://tweakers.net from
7.5s to 3.5s.
This patch synchronizes changes from whatwg/fetch#1569 and
resolves a related FIXME: "Refactor this to the new version of the
spec introduced with whatwg/fetch@464326e.”
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.
Using https://github.com/whatwg/html/pull/9457
(with some changes made to catch up with the current spec)
to fix a spec bug and a crash when removing a visible popover.
I can't find of a way to trigger this codepath, and there is for sure no
correpsonding WPT test, but let's fix this up for whenever it does
become relevant.
This extends the optimization introduced in the previous commit to
also apply to the inserted steps for an option element. This makes
the test:
https://wpt.live/html/select/options-length-too-large.html
Go from not ever completing due to how slow it was to running, to
finishing in 800ms on my PC :^)
We can definitely expand on this a bunch more, but using the metadata
provided in the children change notification we are able to skip
runnning the expensive selectedness algorithm on the <select> element.
This removes children changed from appearing in the profile of:
https://wpt.live/html/select/options-length-too-large.html
Currently, this metadata is only provided on the insertion steps,
though I believe it would be useful to extend to the other cases
as well. This metadata can aid in making optimizations for these
steps by providing extra context into the type of change which
was made on the child.
This is still called _way_ too often, and we need to be much smarter
about when this needs to run. But we get two wins from this very
naive implementation:
1. There is a inner text setter nested within the selectedness
steps uses this list of elements. This saves us building
up a list of elements again within these steps.
2. More importantly, it caches the number of selected elements.
This already allows us to skip a minor amount of work iterating
over the children again. But in future commits, this will serve
as one of the criteria for skipping running the selectedness
algorithm altogether for certain cases, which is a very big win.
A example future idea might be to append to this list directly when
something like appendChild is run instead of iterating over all of
the children again. But that's left as future work.
The spec only refers to this property as something that is on a
Window object, and as far as I can tell this API is only ever
exposed on a Window object anyhow.
This is fundametally broken. A microtask only finishes after all
javascript has finished running. The selectedness of a select element
is observable by javascript, so any changes which are made as a result
of children changing associated with a select element should be made
through the children update steps and friends.
If a calculation was simplified down to a single numeric node, then most
of the time we can instead return a regular StyleValue, for example
`calc(2px + 3px)` would be simplified down to a `5px` LengthStyleValue.
This means that parse_calculated_value() can't return a
CalculatedStyleValue directly, and its callers all have to handle
non-calculated values as well as calculated ones.
This simplification is reflected in the new test results. Serialization
is not yet correct in all cases but we're closer than we were. :^)
Calc simplification eventually produces a single style-value as its
output. This extra context data will let us know whether a calculated
number should be treated as a `<number>` or an `<integer>`, so that for
example, `z-index: 12` and `z-index: calc(12)` both produce an
`IntegerStyleValue` containing 12.
The goal of this VERIFY was to ensure that we didn't mess up the logic
for calculating the correct type. However, it's now unable to do so
because it doesn't have access to the CalculationContext, which
determines what type percentages are. This makes it crash when running
the simplification algorithm. The benefits of this check are small, and
it meant doing extra work, so let's just remove it.
