Per HTML "concept-fe-disabled", only listed elements (button, input,
select, textarea, optgroup, option, fieldset) participate in the
disabled concept. Anything else (e.g. <div disabled>) has no disabled
state and never matches :disabled / :enabled.
Add Element.hasDisabledConcept() and gate isDisabled() on it. Update
the :enabled selector arm so non-form-controls no longer match.
The `:disabled` and `:enabled` pseudo-class matchers in
`webapi/selector/List.zig` only checked the element's own `disabled`
content attribute. Per HTML "selector-disabled" + "concept-fe-disabled"
+ "concept-option-disabled", a form control inside <fieldset disabled>
matches :disabled (with the first-<legend> exception), and an <option>
inside <optgroup disabled> matches :disabled.
Route both pseudo-classes through `Element.isDisabled` (which already
walks the fieldset chain) and extend `isDisabled` to cover the
<option> + <optgroup disabled> case. <option> intentionally does NOT
inherit from <fieldset disabled> or <select disabled> — confirmed
against Chrome.
Closes#2314
Frame.handleClick's .input arm matched only _input_type == .submit and
fell through for .image, so clicking an image button fired the click
event but never scheduled a navigation or dispatched the form's submit
event. Per HTML §4.10.18.6.4 image buttons are submit buttons and must
submit their owning form.
The submitForm path already passes the input element as the submitter,
and FormData.collectForm already handles image submitters by appending
`name.x` and `name.y` (or bare `x`/`y` for unnamed inputs) coordinate
entries to the form-data set. Only the routing in handleClick was
missing. Coordinates are 0 for programmatic .click() per the spec.
Closes#2311
Per upstream review (#2261): Page.handleJavaScriptDialog is a standard
CDP method that reactive Chrome-style drivers send in response to a
Page.javascriptDialogOpening event. Repurposing it for the proactive
pre-arm flow risks surprising those drivers — the next dialog they
trigger would be blindly accepted.
Move the pre-arm handler to LP.handleJavaScriptDialog so only
Lightpanda-aware clients opt in. Page.handleJavaScriptDialog reverts
to the upstream stub returning -32000 "No dialog is showing" so the
reactive surface is unchanged. The Page.javascriptDialogOpening event
listener still pops the BrowserContext stash and fills the response
output param — only the setter moved.
Tests rename cdp.page: → cdp.lp: and target LP.handleJavaScriptDialog;
behavior coverage is identical.
Per the HTML form-data set encoding algorithm, every U+000A (LF) not
preceded by U+000D (CR) and every U+000D (CR) not followed by U+000A
(LF) in an entry's name or value is replaced with the two-byte sequence
CR+LF before percent-encoding. Without this pass, a textarea API value
containing LF (per the textarea wrapping transformation) submits as raw
%0A on the wire instead of the spec-required %0D%0A.
The normalization is gated on URLEncodeMode == .form so URLSearchParams
(.query) still follows the URL standard's serializer, which doesn't
normalize. Same pass covers names + values for both the POST
application/x-www-form-urlencoded body and the GET query-string path
(both go through the same encoder before URL.concatQueryString).
Closes#2307
- Tighten matchesUaDisplayNoneRule docstring; lead with the
centralization purpose and HTML Rendering §15.3.1 spec citation.
- Reorder checks: tag-name UA list first (O(1) switch, exits for
~95% of elements with ordinary tags before the attribute lookup).
- Use el.is(Input) + input._input_type == .hidden instead of
case-insensitive string compare on the raw "type" attribute;
matches the pattern used in EventManager / Form / RadioNodeList,
and _input_type is parsed case-insensitively at attribute-set time.
- Compress the comment block above the matchesUaDisplayNoneRule
call site in isElementHidden.
Behavior-preserving refactor; full unit test suite (494 tests) passes.
