Resolving the cascade for every element on each mutation made an
append + scrollHeight read up to 12x slower. Virtualizers set their
spacer height inline.
A document without a frame isn't rendered, so its extent is zero. The
extent cache moves from Frame to Document with it, and the body lookup
reuses HTMLDocument.getBody.
Only the root scroller's scrollWidth and scrollHeight are floored at the
viewport; html and body keep the document's own height, as in Chrome. The
document's width is body's widest child, and scrollX clamps against it.
html and body reported a fixed 100M px height and window.scrollTo never
clamped. The document height is now the tallest of the synthetic node
positions, body's stacked children and the viewport, and the window
can't scroll past its bottom.
A box whose content is only text had no content extent, so its scroll
offset never clamped. With an explicit width, direct text children now
wrap at it and add their lines to the content height.
An element sized by a stylesheet rule had no explicit size, so its scroll
offset never clamped. The geometry group now tracks width and height, and
getElementAxis reads them from the cascade, which already folds in the
inline style. html and body read only their inline size, without
materializing the style object. Removes the now unused
CSS.parseDimensionViewport.
rebuildIfDirty walks group_fields like the other per-group code, so a new
group needs no change there. Capacities moves out of Group since it
doesn't depend on the spec. Also updates the ownProps and compute call
sites to the (el, frame) order.
Each group owns its rule buckets, its memo and its cascade priorities, so a
rule only joins the groups it declares something in. Visibility keeps
display, visibility, opacity and pointer-events; overflow and
overscroll-behavior move to a geometry group. A visibility probe no longer
matches overflow-only rules, and its memo entry shrinks to 6 bits.
In Runner, when we're `in_cdp` we reduce the HttpClient poll time to 10ms when
a v8 tells us it has a background task. This is to help ensure we don't linger
too long in HttpClient's poll when v8 has work.
But, 10ms can still be long, especially in a WPT test that's running thousands
of WASM compilation in serial. So rather than having a flat 10ms wait, Runner
will now wait 0-10ms, based on (a) whether the last pump had any tasks and (b)
the number of _ticks since there was task.
This is potentially a temporary solution to having v8 wake the HttpClient when
a task is ready.
A parser created via document.open() is only freed when done/close is called
(or some parse error happens). If close() isn't called, the parser is leaked.
This has the Frame track documents that call open so that, on Frame.deinit(),
it can free any parser still associated with the document.
This is the configuration-half of the Sanitizer API. In a follow up, we'll add
the missing element.setHtml and sanitizer option to the existing setHTMLUnsafe
(as well as the ShadowRoot and Document sanitizer-aware methods).
I'm stealth adding these changes to the log-msg-limit branch/PR because...
This branch reverts a previous intentional change https://github.com/lightpanda-io/browser/pull/2690
which positively impacted memory usage. However #2690 did a couple things, and
changing `comptime msg: []const u8` to `msg: []const u8` was the most
insignificant. So, I was hoping this change would be ok, the real memory gain
of 2690 probably have nothing to do with the comptime message.
BUT, I wanted to make sure, so I re-generated the orderfile on this branch, to
get the CI report for an optimal build. And the memory went +4MB, which seemed
impossible. Turns out my local ../demo was in a weird state from some WebDriver
testing yesterday and nothing was ever executed. So the orderfile I generated
was meaningless.
So, I'm now (a) including optimized orderfiles for this branch and (b) making
regen.sh fail if the bench doesn't seem to successfully run
Comptime msg validation was removed in https://github.com/lightpanda-io/browser/pull/2690
as part of a memory reduction effort. But that PR did more than just remove the
comptime msg (and thus the comptime msg check). So I want to see what the memory
usage is with an ideal orderfile.
logToErased asserts that a log message is at most 30 characters of
plain text, but only in a debug build and only once the line actually
runs. A message on a rare path therefore ships fine and then panics on
whoever first reaches it: `serve --host 0.0.0.0` without
--advertise-host crashed on startup in every debug build, because
"advertising loopback for wildcard bind" is 38 characters.
Every message is a literal, so make the six wrappers take a comptime
msg and apply the same two rules through @compileError. The runtime
check stays as the backstop for the paths the compiler does not
analyse for the current target, and now reads the same constant.
Eleven messages were over the limit; shorten them. The detail already
lives in the kv pairs in each case. renderFailed takes its message as
comptime now, the only call site that passed a runtime one.
Note the check only covers code analysed for the target being built:
the two in Certificates.zig sit in an OS switch prong that Linux never
compiles, and were found by scanning the source rather than by the
compiler.