Closing the divergence introduced by the new IDL accessors: `submitter.formEnctype`
(and `form.enctype`) now return "text/plain" for that attribute value per WHATWG
HTML §4.10.21.5, but `Frame.submitForm` previously fell back to urlencoded with
a `.not_implemented` log when it saw the same value on the submission path.
Implement the spec's text/plain encoding algorithm (HTML §4.10.21.8):
- FormData.EncType gains a `.plaintext` variant.
- FormData.plaintextEncode writes "name=value CRLF" per entry, no URL-encoding,
no escaping — the spec accepts that text/plain is a lossy, human-readable
encoding (values containing "=" or CRLF produce an ambiguous wire format
by design).
- Frame.submitForm recognizes "text/plain" before the urlencoded fallback and
sets the Content-Type header to "text/plain; charset=<form-charset>", per
spec step 21.4.
Two new Zig unit tests cover encoding output (`FormData: plaintext write`,
`FormData: plaintext empty body`). Full suite 639/639 green.
This is bundled with the IDL accessor commits because returning "text/plain"
from the IDL while the submission silently re-encodes as urlencoded is a
spec-internal inconsistency the IDL change itself introduces. Reviewers who'd
prefer to land just the read-only accessors first should feel free to ask for
a split — this commit is self-contained and reverts cleanly.
Move FormData from using KeyValueList to using its own List(Entry), where
entry's value is a union over a String or File. Preparatory stuff for input
type=file support.
Per review: collectForm walked the children once to look for a
non-disabled <option>, then Select.getValue walked them again to
emit the value. Extract the selectedness-candidate algorithm into
Select.effectiveOption() ?*Option so both call sites share it and
each runs a single iteration.
- Select.getValue is now a one-liner over effectiveOption.
- collectForm replaces the candidate-check + getValue pair with
`select.effectiveOption() orelse continue; break :blk opt.getValue(frame);`.
Behavior is unchanged; the existing form_data.html fixtures
(selectWithoutOptions, selectMultipleWithoutOptions,
selectAllOptionsDisabled) still pass.
Per the HTML Living Standard "constructing the form data set" algorithm,
a <select> element appends one entry per option whose selectedness is
true. A non-multiple <select> derives its selectedness from an
explicitly-selected option, falling back to the first non-disabled
option in tree order. With zero options (or only disabled options), no
option is selected, so no entry should be appended.
The singular-select fast path in collectForm previously broke from the
block with select.getValue(frame) regardless of whether any option
existed, causing FormData to emit a phantom (name, "") entry for an
empty <select>. Guard the fast path on the existence of at least one
non-disabled <option> child and skip the entry otherwise.
Closes#2262
This is to pave the way for introducing a new "Page" container, which will take
over the page lifecycle currently burdening Session. The ultimate goal of that
is to allow the Session to have multiple pages (mostly for better transitions
between pages), which is hard to do now since the Session has so much state.
This rename was aggressive, e.g. currentPage() -> currentFrame() so that, when
the new Page container is added, you won't see "currentPage()" and wonder:
"Does 'currentPage' mean the new Page container, or the Frame (which
used to be called Page)".
@import("lightpanda") where needed.
Would also like to do this for String, Page, Session and js which all stand out
as types that are use across the codebase.
I know that a few devs are doing this in new work and I haven't heard anyone
voice an objection.
A Worker has no page. So any API that is accessible to a worker cannot take
a *Page parameter. Such APIs will now take a js.Execution which the context
will own and create from the Page (or from the WorkerGlobalScope when that's
created).
To test this, in addition to introducing the Execution, this change also updates
URLSearchParams which is accessible to Worker (and the Page obviously). This
change is obviously viral..if URLSearchParams no longer has a *Page but instead
has an *Execution, then any function it calls must also be updated.
So some APIs will take a *Page (those only accessible from a Page) and some will
take an *Execution (those accessible from a Page or Worker). I'm ok with that.
A lot of private/internal functions take a *Page, because it's simple, but all
they want is a call_arena or something. We'll try to update those as much as
possible. The Page/Execution being injected from the bridge is convenient, but
we should be more specific for internal calls and pass only what's needed.
