fix(sirius-press): wallet sign-in did not work in an actual browser

Two bugs, both invisible to every test written so far, because those tests
post to wp-login.php over HTTP and a browser does not.

**The submit was blocked.** WordPress marks its username and password inputs
`required`. The wallet path deliberately leaves both empty — the signature is
the credential — so `form.requestSubmit()` ran constraint validation, refused,
and pointed a "Please fill out this field" bubble at an input the visitor is
not supposed to touch, with a valid signature already sitting in the form.
Nothing happened and nothing explained why. The wallet submit now turns
validation off for that submission only; password sign-in keeps it.

**`hidden` did not hide.** The attribute works through a UA rule that any
author rule with a `display` outranks, and WordPress ships exactly such a
rule — `.wp-core-ui .button { display: inline-block }`. So the two buttons
this plugin ships hidden were on screen regardless. That inverted the whole
progressive-enhancement story: "Use the browser wallet" was offered on every
browser including those without one, and a visitor with JavaScript disabled
would have been shown a sign-in button that could never do anything, instead
of the paste-a-signature box that works without scripts.

Found by opening the login page in a browser and clicking the button, which
is the one thing 178 passing checks had not done.
This commit is contained in:
Silent Mode 2026-09-22 20:06:27 +02:00
parent 8e17bc6514
commit 2287138149
2 changed files with 29 additions and 0 deletions

View file

@ -7,6 +7,24 @@
* as the way in, and the password field above it reads as a leftover. * as the way in, and the password field above it reads as a leftover.
*/ */
/*
* Make the `hidden` attribute actually hide things.
*
* `hidden` works through a UA rule `[hidden] { display: none }` which any
* author rule carrying a `display` outranks. WordPress ships exactly such a
* rule: `.wp-core-ui .button { display: inline-block }` in buttons.css, which
* matches every button in this block.
*
* Without this the whole progressive-enhancement story silently inverts. The
* markup ships with the sign-in button, the browser-wallet button and the
* phrase field hidden, and the script reveals only the ones that can work.
* Defeat `hidden` and a visitor with JavaScript off is offered a button that
* does nothing, and everyone is offered a browser wallet that is not there.
*/
.sirius-wallet [hidden] {
display: none !important;
}
.sirius-wallet { .sirius-wallet {
margin: 16px 0 8px; margin: 16px 0 8px;
padding: 16px; padding: 16px;

View file

@ -33,6 +33,17 @@
function submitForm(block) { function submitForm(block) {
const form = block.closest("form"); const form = block.closest("form");
if (!form) return; if (!form) return;
// WordPress marks its username and password inputs `required`, and the
// wallet path deliberately leaves both empty — the signature is the
// credential. Constraint validation would otherwise refuse the submit and
// point a "Please fill out this field" bubble at an input the visitor is
// not supposed to touch, with the signature already sitting in the form.
//
// Only reached from the wallet buttons, so password sign-in keeps its
// validation.
form.noValidate = true;
if (typeof form.requestSubmit === "function") { if (typeof form.requestSubmit === "function") {
form.requestSubmit(); form.requestSubmit();
} else { } else {