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.
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).
Muki Kiboigo