Previously we were making a copy of the full set of custom properties
that applied to a DOM element. This was very costly and dominated the
profile when mousing around on GitHub.
Note that this may break custom properties on pseudo elements a little
bit, and that's something we'll have to look into.
Computing the pseudo element of a CSS::Selector was very hot when
mousing around on GitHub in Browser. A profile had it at ~10%.
After these changes, it's totally gone from the profile. :^)
Instead of calling quick_sort() every time a StackingContext child
is added to a parent, we now do a single pass of sorting work after the
full StackingContext tree has been built.
Before this change, the quick_sort() was ~13.5% of the profile while
hovering links on GitHub in the Browser. After the change, it's down to
~0.6%. Pretty good! :^)
Also use the daylight global to determine the current time zone name,
i.e. tzname[0] is standard time, tzname[1] is daylight savings time.
Note that altzone isn't required to be defined on all systems, so we
have to #ifdef to check if it exists in order for Lagom to build.
This was not handling the nullary call case correctly, remove the whole
nullary check as there's nothing particularly expensive in the catch-all
case anyway.
For seletors whose subject is unversal (i.e selectors that end in "*")
we were not serializing the asterisk. Instead "foo bar *" came out as
"foo bar foo". This patch fixes that by correctly serializing the last
simple selector if it's universal.
The smooth scrolling looks slightly off in the terminal as the
scrollbar animation lasts longer than the actual scroll.
This behaviour is also consistent with other terminal emulators.
-Layer now has methods for flip/rotate/crop, which are responsible
for handling the alpha mask.
-Fixed crash when the display image size is out of sync with
the content image size.
-Changed API for setting content and mask image in Layer. Now, both
must be set at the same time, and it can result in an error if
you provide mismatched dimensions.
Simplify automatic cross sizing of items in flex-direction:column by
using the fit-content width directly.
There's obviously a lot more nuance to this, but for now this makes
flex items with both width:auto and height:auto actually get some height
in column flex layouts.
I'm a little confused about intrinsic heights *really* work, and I'm
struggling to extract that information from the spec. In the meantime,
let's ensure that min-content is always smaller than (or equal to)
max-content so that other math works as expected.
Previously, each NodeState in a FormattingState was shared with the
parent FormattingState, but the HashMap of NodeState had to be copied
when making FormattingState copies.
This patch makes copying instant by keeping a pointer to the parent
FormattingState instead. When fetching immutable state via get(), we may
now return a reference to a NodeState owned by a parent FormattingState.
get_mutable() will copy any NodeState found in the ancestor chain before
making a brand new one.
The flexbox specification barely even handwaves about automatically
sized items, but there's actually a lot of work to do in order for them
to get the correct size.
This patch is messy, but does make significant progress on supporting
flex items with indefinite width and/or height.
There's a fair amount of nested layout going on here, but do note that
we'll be hitting the intrinsic sizes cache whenever possible.
FormattingContext can now calculate the intrinsic sizes (min-content and
max-content in both axes) for a given Layout::Box.
This is a rather expensive operation, as it necessitates performing two
throwaway layouts of the subtree rooted at the box. Fortunately, we can
cache the results of these calculations, as intrinsic sizes don't change
based on other context around the box. They are intrinsic after all. :^)
This wasn't worth the headache of trying to make SVG boxes work together
with BFC right now. Let's just make it a block container once again, and
have its corresponding SVGPaintable inherit from PaintableWithLines.
We'll have to revisit this as SVG support improves.
Although something has a definite size, we may still have to "resolve"
it, since FFC is quite liberal in what it considers to be definite.
Let's put that logic in a set of helper functions.
1. Make this decision *after* we've inserted the layout node into the
layout tree. Otherwise, we can't reach its containing block!
2. Per css-sizing-3, consider auto-sized blocks whose sizes resolve
solely against other definite sizes as definite themselves.
In particular, (2) makes us consider width:auto block children of a
definite-size containing block as having definite size. This becomes
very important in flex layout.
If there's some non-block-level box (like an SVG element of some kind)
between to blocks, just skip over the non-block for purposes of margin
collapsing. This is basically a hack, and something we'll need to
improve as part of our general SVG support.
For single-line flex containers, center the only flex line along the
cross axis. Alignment of multi-line flex containers are left as a FIXME.
This patch also moves out the assignment of final metrics to the
FormattingState from align_all_flex_lines() to a separate function.
- Avoid performing inside layout on definite-size flex items (since
their computed size can be used as-is.)
- Use FormattingState::clone() to generate a throwaway layout instead of
mutating the tree in-place.
- Update spec link & comments based on current CSSWG draft. The latest
version is quite a bit clearer on how this should work.
Instead of doing internal child layout incrementally as we go, save it
for the end of flex layout. The code will become simpler if we can focus
on simply computing the dimensions of each flex item while we're doing
the main FFC algorithm.
We don't need to perform inside layout here. The only information we
need in this step is whether an anonymous block container has nothing
but empty-or-whitespace text children.
This information is already accurate after the initial layout tree
construction. Performing a layout does not change the answer. It does
however have many other side effects, so let's defer those.
This implements at least some of the specification. inter-character is
not yet handled. However as our current algorithm only considers
whitespace as word breaks, inter-word could technically be considered to
be handled. :^)
All the justification-related code is now in
InlineFormattingContext::apply_justification_to_fragments and is
performed after all the line boxes have been added.
Text justification now only happens on the last line if the excess space
including whitespace is below a certain threshold. 10% seemed reasonable
since it prevents the "over-justification" of text. Note that fragments
in line boxes before the last one are always justified.
When doing viewbox transforms, elliptical always had large arc and
sweep flag set to false. Preserve these flags so they can be set
correctly when applying viewbox transformations.
The absolute rect of a paintable is somewhat expensive to compute. This
is because all coordinates are relative to the nearest containing block,
so we have to traverse the containing block chain and apply each offset
to get the final rect.
Paintables will never move between containing blocks, nor will their
absolute rect change. If anything changes, we'll simpl make a new
paintable and replace the old one.
Take advantage of this by caching the containing block and absolute rect
after first access.
On the code path where we are setting a TypedArray from another
TypedArray of the same type, we forgo the spec text and simply do a
memmove between the two ArrayBuffers. However, we forgot to apply
source's byte offset on this code path.
This meant if we tried setting a TypedArray from a TypedArray we got
from .subarray(), we would still copy from the start of the subarray's
ArrayBuffer.
This is because .subarray() returns a new TypedArray with the same
ArrayBuffer but the new TypedArray has a smaller length and a byte
offset that the rest of the codebase is responsible for applying.
This affected pako when it was decompressing a zlib stream that has
multiple zlib chunks in it. To read from the second chunk, it would
set the zlib window TypedArray from the .subarray() of the chunk offset
in the stream's TypedArray. This effectively made the decompressed data
from the second chunk a mis-mash of old data that looked completely
scrambled. It would also cause all future decompression using the same
pako Inflate instance to also appear scrambled.
As a pako comment aptly puts it:
> Call updatewindow() to create and/or update the window state.
> Note: a memory error from inflate() is non-recoverable.
This allows us to properly decompress the large compressed payloads
that Discord Gateway sends down to the Discord client. For example,
for an account that's only in the Serenity Discord, one of the payloads
is a 20 KB zlib compressed blob that has two chunks in it.
Surprisingly, this is not covered by test262! I imagine this would have
been caught earlier if there was such a test :^)
Previously this queried the root layout-node's font, which was both
wrong and could crash if the layout wasn't ready yet. Now, it's just
wrong. But at least all the font-related wrongness is grouped together
in StyleComputer. :^)
In testing a particular website (https://www.icpms.com), WebContent
was crashing with infinite recursion in draw_circle_arc_intersecting.
Presumably, radius must be > 0 to paint something, so this trivial
patch simply returns if radius <= 0. The website in question no longer
crashes WebContent.
This reverts commit 5d51e26caf.
The threadlocal Vector was somehow misaligned, causing UBSAN to be sad
about calling a misaligned method (either the dtor or .is_empty()) on
it.
For now, let's revert this and avoid the CI flake.
Fixes#12957.
Everything related to hit testing is better off using the painting tree.
The thing being mousemoved over is a paintable, so let's hand that out
directly instead of the corresponding layout node.
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
This patch adds a bunch of Paintable subclasses, each corresponding to
the Layout::Node subclasses that had a paint() override. All painting
logic is moved from layout nodes into their corresponding paintables.
Paintables are now created by asking a Layout::Box to produce one:
static NonnullOwnPtr<Paintable> Layout::Box::create_paintable()
Note that inline nodes still have their painting logic. Since they
are not boxes, and all paintables have a corresponding box, we'll need
to come up with some other solution for them.
BlockContainer paint boxes are the only ones that have line boxes
associated, so let's not waste memory on line boxes in all the other
types of boxes.
This also adds Layout::Box::paint_box() and the more tightly typed
Layout::BlockContainer::paint_box() to get at the paint box from the
corresponding layout box.
The "paintable" state in Layout::Box was actually not safe to access
until after layout had been performed.
As a first step towards making this harder to mess up accidentally,
this patch moves painting information from Layout::Box to a new class:
Painting::Box. Every layout can have a corresponding paint box, and
it holds the final used metrics determined by layout.
The paint box is created and populated by FormattingState::commit().
I've also added DOM::Node::paint_box() as a convenient way to access
the paint box (if available) of a given DOM node.
Going forward, I believe this will allow us to better separate data
that belongs to layout vs painting, and also open up opportunities
for naturally invalidating caches in the paint box (since it's
reconstituted by every layout.)
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/26a4c4f
No behavioral change as we already did this correctly, but I changed
some implicit JS::Value creations to explicit ones.
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/983902e
We already had these defined as structs, but now they're properly
defined in the spec (opposed to the previous anonymous records), and we
don't have to make up our own names anymore :^)
Note that while we're usually not including 'record' in the name, in
this case the 'Duration Record' has a name clash with the Duration
object. Additionally, later editorial changes introduce CreateFooRecord
AOs, so let's just go with FooRecord structs here.
The blank string "" does not parse as JSON, and so the InspectorWidget
would fail to update the box-model information when inspecting elements
with no box, (for example, `<head>`) showing stale values instead. Now,
they show all 0s.
You could argue that InspectorWidget should be more resilient when given
invalid JSON strings, but making sure we only pass valid ones works
too.
This expands the InspectorWidget::Selection to include an optional
PseudoElement, which is then passed over IPC to request style
information for it.
As noted, this has some pretty big limitations because pseudo-elements
don't have DOM nodes:
- Declared style has to be recalculated when it's requested.
- We don't display the computed style.
- We don't display custom properties.
read_length in WebSocket::read_frame is used to track how many bytes we
have read in from the network. However, we was subtracting the number
of read in bytes instead of adding, underflowing it to about the 64-bit
unsigned integer limit.
This effectively limited us to only doing one read from the network.
This was only an issue if the server stalled when sending data,
which is especially common for large payloads. This would also cause us
to go out of sync. This meant when a new frame came in, we would read
the payload data of the previous frame as if it was the frame header
and payload of the next frame.
This allows us to read in the initial payload from Discord Gateway
that describes to the client the servers we are in, the emotes the
server has, the channels it has, etc. For an account that's only in
the Serenity Discord, this was about 20 KB (compressed!)
This resolves the ambiguity between whether a single number is a number
or a ratio. :^)
Also removed the "no more tokens" checks from
deea129b8c - that logic was completely
wrong, since there are always tokens after a value in the `(123 < foo <
456)` syntax.
This works largely the same as the PropertyID and ValueID generators,
but using LibMain, Core::Stream, and TRY().
Rather than have a MediaFeatureID::Invalid, I decided to return an
Optional. We'll see if that turns out better or not. :^)
This data will be used to generate code for parsing media-queries. So
far, it includes all MEDIAQUERIES-4 features, and
`prefers-color-scheme` from MEDIAQUERIES-5 since we support that.
This merges GLContext and SoftwareGLContext into a single GLContext
class. Since the hardware abstraction is handled via the GPU device
interface we do not need the virtual base of GLContext anymore. All
context handling functionality from the old GLContext has been moved
into the new version. All methods in GLContext are now non virtual and
the class is marked as final.
When rules are inserted or removed via the CSSOM API, we now invalidate
document style to ensure that any changes made are reflected.
1% progression on ACID3. :^)
Previously the variable and lexical environments were already kept in a
NativeFunction call. However when we (try to) call a private method from
within an async function we go through async_block_start which sets up
a NativeFunction to call.
This is technically not exactly as the spec describes it, as that
requires you to actually "continue" the context. Since we don't have
that concept (yet) we use this as an implementation detail to access the
private environment from within a native function.
Note that this not allow general private environment access since most
things get blocked by the parser already.
Let's get this right before trying to make it fast. This patch removes
the code that tried to do less work when an element's style changes,
and instead simply invalidates the entire document.
Note that invalidations are still coalesced, and will not be
synchronized until update_style() and/or update_layout() is used.
If the style is dirty, update_style() may cause layout to become dirty.
Therefore we must always update style when updating layout, to ensure
up-to-date results.
This forces us to recompute style everywhere, since all kinds of
selectors may produce different results now.
In the future, we should look at narrowing down the invalidation that
occurs here, but for now let's just invalidate everything and make the
results correct before worrying about performance.
We were handing out stale values from window.getComputedStyle() objects
after the first layout.
Fix this by always updating layout on property access. This is not
necessary for all properties, but for now let's go with the simplest
approach to make it work correctly.
These steps run when a node is about to be removed from its parent,
and adjust the position of any live NodeIterators so that they don't
point at a now-removed node.
Note that while this commit implements what's in the DOM specification,
the specification doesn't fully match what other browsers do.
Spec bug: https://github.com/whatwg/dom/issues/907
