We've historically asserted that no "saturated" size values end up as
final metrics for boxes in layout. This always had a chance of producing
false positives, since you can trivially create extremely large boxes
with CSS.
The reason we had those assertions was to catch bugs in our own engine
code where we'd incorrectly end up with non-finite values in layout
algorithms. At this point, we've found and fixed all known bugs of that
nature, and what remains are a bunch of false positives on pages that
create very large scrollable areas, iframes etc.
So, let's change it! We now clamp content width and height of boxes to
17895700 pixels, apparently the same cap as Firefox uses.
There's also the issue of calc() being able to produce non-finite
values. Note that we don't clamp the result of calc() directly, but
instead just clamp values when assigning them to content sizes.
Fixes#645.
Fixes#1236.
Fixes#1249.
Fixes#1908.
Fixes#3057.
While keyword_to_foo() does return Optional<Foo>, in practice the
invalid keywords get rejected at parse-time, so we don't have to worry
about them here. This simplifies the user code quite a bit.
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.
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.
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.
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.
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.
Corresponds to https://github.com/whatwg/html/pull/10904
However, we don't implement most of what is changed in that PR, so this
simply moves the FIXME'd getContextAttributes() method from one place
to another.
Previously, we were generating timestamps relative to the current time
of the monotonic clock. We now generate timestamps relative to the
event loop's last render opportunity time, per the spec.
