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.
The cascade expanded overscroll-behavior into longhands but
CSSStyleDeclaration didn't, so setting the shorthand left
overscrollBehaviorX reading empty and a style= block round-tripped
through the object lost it.
CssParser.axis_shorthands is now the one list, with axisShorthand and
axisLonghand as the lookups both sides use: the CSSOM's overflow-only
special cases (set, apply, remove, priority, serialize) became that
lookup, and OverflowPair became AxisPair. Verified against Chrome 153:
`overscroll-behavior: contain auto` reads back per axis, collapses to
`contain` when both match, and serializes as one declaration.
writeScroll held the map entry across the clamp, which reads styles and
walks children, and it created an entry even for a write that changed
nothing. It now clamps both axes against a plain lookup and only takes
the entry when an offset actually moves.
That makes the write itself the answer to "can this container move?", so
the wheel walk asks by writing instead of recomputing the extent first,
and canScrollAxis is gone.
Adds the ability to execute JavaScript via WebDriver. The other webdriver
endpoints were able to re-use the existing BiDi code (e.g. navigating via
webdriver or bidi quickly ends up in the same function). But for execute, it's
completely different, from input parameters, to running the code, to the result
that's returned. So there's a dedicated handler for this: `execute.zig`. But
the rest of the infrastructure (the http waiting for a reply, the routing, the
parameter parsing, ... are all the same).
TryCatchRethrow, JsException and ExecutionTerminated all mean V8 already
has something pending: creating an error value and aborting the stream
would replace the exception the script is meant to see, or hand a killed
script a catchable Error. Drop the streaming handle instead, matching the
early exit in Caller.handleError.
Element.focus() would "focus" the element even when it shouldn't. We already
have the logic to determine if an element is focusable in `user_input.zig`, so
this was moved to Element and is now used in el.focus().
Some status-codes should never have a body except for a single trailing blank
line. If we don't handle these, then we end up with a dirty connection in our
connection pool:
1 - read the header, but not the body
2 - put the connection back in the pool
3 - try to read the header, but actually get the body from #1
WPT /fetch/api/basic/response-null-body.any.html exercises this path and is
flaky (because it depends whether the request goes back out on a keep-alive
connection)..but for a given run,you'll almost always get 1-3 failures.
This commit processes the request, but tells libcurl not to re-use the
connection.
wheelScroll handed the whole delta to the nearest scroll container on
each axis, whatever state it was in, so a saturated inner scroller
trapped the wheel and the page never moved.
scrollAxis walks outward per axis and gives the whole delta to the first
container that can still move along it. A delta is never split: a
container that can only take part of it keeps the rest, and the page
moves on the next wheel. That is Chrome's rule in FindNodeToLatch
(cc/input/input_handler.cc), confirmed against Chrome 153 - one wheel of
1000px over a container with 416px of travel leaves window.scrollY at 0.
A container whose overscroll-behavior doesn't propagate takes the latch
even when it can't move, which ends the walk.
Chaining a wheel out of a saturated container is exactly what sites use
`overscroll-behavior: contain` to prevent, so the cascade needs to know
about it before the wheel can chain.
Two flags follow the overflow-x/overflow-y pattern: a shorthand arm in
Slots.apply covers both fold paths, and overscrollContainAxes is the
probe. `contain` and `none` both stop propagation, only `auto` lets it
through. Props was exactly full at u8.
splitOverflow serves two shorthands now, so it is splitAxisPair.
Every scroll write clamped at zero and nothing else, so an offset could
exceed the scrollable extent without limit and a page probing
`scrollTop >= scrollHeight - clientHeight` got a number Chrome would
never produce.
Element.scrollExtent is that bound, and setScrollTop/setScrollLeft/
scrollTo/scrollBy now share one writer that applies it. The extent is
optional and null means unbounded: without a layout engine there is no
honest box for an element sized by a stylesheet (getElementAxis reads
only inline width/height) or one holding text (contentAxis sums element
children), and refusing a scroll we can't prove impossible is worse than
allowing one too many. html and body are excluded outright, so the
viewport keeps its fabricated extent and stays unbounded.
Chrome clamps all three, so the HTML fixture asserts the limit
relationally - a real browser reserves scrollbar space in clientHeight
and lands a few px lower. The gap we keep is pinned in a Zig test
instead.
The write path also does its arithmetic in i64: the old relative path
could panic on an offset stored above maxInt(i32).
Karl Seguin