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.
Instead of adding a flag for the two callers that need a pop of the
execution context stack when invoking continue_async_execution inline
the pop of the execution context.
This makes the management of these stacks and surrounding VERIFY calls
much more obvious.
This has no functional difference as run_queued_promise jobs does
nothing when LibWeb is used as it has a different implementation of
enqueuing and running promise jobs. But this change makes it more
obvious that run_queued_promise jobs does nothing when there is an
embedder, and adjusts the comment to reflect what the code is
actually achieving.
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.
Calc simplification (which I'm working towards) involves repeatedly
deriving a new calculation tree from an existing one, and in many
cases, either the whole result or a portion of it will be identical to
that of the original. Using RefPtr lets us avoid making unnecessary
copies. As a bonus it will also make it easier to return either `this`
or a new node.
In future we could also cache commonly-used nodes, similar to how we do
so for 1px and 0px LengthStyleValues and various keywords.
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.
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
BFC roots behave differently in that their height is computed twice,
before and after inside layout, since automatic height depends on the
results of inside layout. Other formatting contexts only require the
"before" pass, and so we can treat their content sizes as definite
before proceeding with inside layout.
This makes https://play.tailwind.com/ look beautiful. :^)
The focus chain always consists of newly created GC::Root objects, so
the condition always produced `false`. The fix is to use GC::Root's
overloaded operator== method, which compares the pointers of the stored
type.
This fixes Figma dropdowns and context menus instantly disappearing
upon opening them. This is because they become focused when they insert
them. Because of this bug, it would fire blur events all the way up to
and including the window. Figma listens for the blur event on the
window, and when received, it will instantly hide dropdowns and context
menus. The intention behind this seems to be hiding them when the user
clicks off the browser window, or switches tab.
Several interfaces that return a high resolution time require that
time to be coarsened, in order to prevent timing attacks. This
implementation simply reduces the resolution of the returned timestamp
to the minimum values given in the specification. Further work may be
needed to make our implementation more robust to the kind of attacks
that this mechanism is designed to prevent.
