Saw a site return "Content-Type: charset=UTF-8;charset=UTF-8" on scrape. Not a
valid header and it correctly fails to parse. Except...CDP fails to RI on these
since it tries to parse and bubbles. Safe to swallow this error here and
continue with the response serialization.
Resolving the cascade for every element on each mutation made an
append + scrollHeight read up to 12x slower. Virtualizers set their
spacer height inline.
If the server gives a status reason, report it as-is. Only default to the
zig code->reason map when one isn't given.
Also, don't force a 407 status code when auth_challenge is present.
https://github.com/lightpanda-io/browser/pull/3619 added proper support for
Sanitizer. A consequence of that is that every setHTML/parseHTML without an
explicit creates the default Sanitizer (with its ~300 entries).
This commit creates 1 app-level default sanitizer and uses it, internally, when
none is explicitly given. The sanitizer is immutable so can safely be used
across threads.
Adjacent placeholder anchors, like a JS-driven nav, ran together as
HomeAbout. Keep the standalone line placement linked anchors get and
drop only the link syntax.
`lightpanda version.io` was rejected as a misspelt `version`, 3 edits
within the length-scaled limit. Like curl, it fetches now: the command check
shares --dump's isUrlLike.
Following some experimentation, this sets M_MMAP_THRESHOLD to 128K on linux
builds IF it isn't explicit set, e.g. via the `MALLOC_MMAP_THRESHOLD_` env. This
allows users explicitly set it if they want.
I've been looking at this for a while, but my understanding is still basic. The
simplistic explanation is that glibc's allocator internally uses arenas.
Allocations above THRESHOLD skip these arenas and are allocated directly from
and freed directly to the OS. Allocations under this threshold are released
to the arena where they can be re-used. Everything works OK, EXCEPT for when it
comes time to release the memory from these arenas back to the OS. If free arena
memory is pinned under live memory, it cannot be released.
Various online posts / comments reference glibc as suffering from significant
fragmentation and "holding" onto memory. That's the behavior that we've seen.
Further, calls to malloc_trim reclaim the lost memory, so what we're seeing
aren't leaks.
Since AttachedSession is already heap-based, it's inspector_session is at a
fixed address and thus can own the session.
Also, hook in some noop callbacks on deinit.
Encode the !important'ness of a rule into its priority (we have the bit to
spare). This keeps the !important calculation the build-side, not the read side
and is more consistent with how the StyleManager generally works.
CSSStyleDeclaration `getPropertyValue` is now !important aware. Whereas before
an inline value would always win, it now cedes to an !important stylesheet rule
While the token list itself is readonly, the attribute itself is settable. For
example, HTMLOutputElement's htmlFor says:
"Although the htmlFor property itself is read-only in the sense that you can't
replace the DOMTokenList object, you can still assign to the htmlFor property
directly"
Karl Seguin