DEV Community: cometa-kaito

"An invalid form control is not focusable": Hidden Steps

cometa-kaito — Sun, 18 Oct 2026 08:14:11 +0000

The short version

A three-step application form was built as a single <form>, with each step shown or hidden using the hidden attribute (equivalent to display:none). The required fields live on step 1; the submit button lives on step 2. Step 1's "Continue to confirmation" button is type="button" and validates nothing, so a user can reach step 2 with required fields still empty. Pressing the step 2 submit button (type="submit") then triggers the browser's native validation, which finds the empty required fields — but by then step 1's section is hidden and unfocusable, so the browser has no way to surface an error and silently aborts the submit. The fix: add noValidate to the form to disable native validation, and run an explicit check inside "Continue to confirmation" that renders an error message on the spot instead.

Symptom

The /apply form for signing up for the school-advertising support program has three steps — choose a school (step 0), enter listing details and contact info (step 1), and confirm and submit (step 2) — driven by a step value in useState. All three steps' inputs live inside a single <form action={formAction}>, and which step is visible is decided purely by wrapping each step in a <section> with the hidden attribute.

<form action={formAction}>
  {/* STEP 0: choose school + period */}
  <section hidden={step !== 0}>...</section>

  {/* STEP 1: listing content (required contact fields live here) */}
  <section hidden={step !== 1}>
    ...
    <input id="sf_name" name="name" required maxLength={200} ... />
    <input id="sf_email" name="email" type="email" required maxLength={200} ... />
    ...
    <button type="button" onClick={() => setStep(2)}>Continue to confirmation</button>
  </section>

  {/* STEP 2: confirm and submit (the only submit button is here) */}
  <section hidden={step !== 2}>
    ...
    <button type="submit" disabled={pending}>Submit</button>
  </section>
</form>

During a live production walkthrough by the author and Claude, we advanced to the step 2 confirmation screen without ever filling in the contact name or email, and pressing "Submit" produced no change on screen whatsoever — no error message, no loading state, not even a visible reaction to the click. The only trace was a single warning in the browser devtools console:

An invalid form control with name='name' is not focusable.

Cause

Moving between steps is implemented with a type="button" that only mutates React state.

<button type="button" onClick={() => setStep(2)}>
  Continue to confirmation
</button>

Clicking a type="button" is not a form submission, so native browser input validation never runs here at all. The required name and email fields can be empty and the user still advances straight to the step 2 confirmation screen without any friction.

The only type="submit" button anywhere in the form is "Submit," on step 2.

<button type="submit" disabled={pending}>
  {pending ? "Submitting…" : "Submit"}
</button>

The moment a user presses it, the browser runs native HTML5 validation against the entire <form>. name and email are required, so an empty value is correctly flagged as invalid — but at this point step is 2, and the step 1 section containing those fields has hidden={step !== 1} evaluate to true, making it display:none. An element with display:none cannot receive focus. The browser tries to focus the offending field to show the validation error to the user, fails, logs a warning to the console, and silently cancels the submission. No visible error, no scroll, nothing.

In other words, what looked like "the user can just fill in the required field later" was actually a structure where the only way to reach that required field was already gone from the screen by the time submission was attempted.

Fix

noValidate was added to the form element, disabling native browser validation entirely.

{/* noValidate: the input gate is goConfirm (which shows errors) plus server-side
    validation. Native validation silently blocks when a required field sits in a
    hidden section, which looks like a hang, so it's disabled. */}
<form action={formAction} noValidate>

In its place, step 1's "Continue to confirmation" button now calls goConfirm, which runs an explicit check.

const goConfirm = () => {
  const missing: string[] = [];
  if (creativeMode === "omakase") {
    if (!omBiz.trim()) missing.push("business type");
    if (!omMessage.trim()) missing.push("key message");
  }
  if (!company.trim()) missing.push("business/company name");
  if (!contactName.trim()) missing.push("contact name");
  if (!email.trim()) missing.push("email address");
  else if (!EMAIL_RE.test(email.trim()))
    missing.push("email address (check the format)");
  if (missing.length > 0) {
    setStepError(`Missing fields: ${missing.join(", ")}`);
    return;
  }
  setStepError(null);
  setStep(2);
};

If anything is missing, a role="alert" message renders right there — on step 1, which is still visible — and the user is not advanced to step 2.

{stepError && (
  <p role="alert" className="mt-4 rounded-lg border border-red-200 bg-red-50 px-3 py-2 text-sm text-red-700">
    {stepError}
  </p>
)}

This check can also cover fields the HTML5 required attribute never saw, like the business type and key message that only apply when omakase mode is selected. Native validation only looks at fields marked required; goConfirm can express business rules (these two fields are mandatory only in omakase mode) directly in code. Final validation is still left to the server-side Server Action, unchanged.

Prevention

Packing multiple steps of input into a single <form> and toggling visibility with hidden is fundamentally at odds with native HTML5 validation. Browser input validation looks at the whole form and hunts for "the first invalid field that can receive focus" — it has no concept of which step is currently displayed. The moment required fields and the submit button end up on different steps, it becomes possible for the field validation needs to reach right when submission is attempted to have already vanished from the screen.

To stay safe with this pattern, pick one of two approaches up front: (1) treat any multi-step form as noValidate by default and write an explicit check on every step transition, or (2) split each step into its own separate <form> so native validation stays self-contained within a single step. A form that "looks like it works but silently can't submit" is hard to catch with automated tests — this one only surfaced through a live, hands-on walkthrough in production.

Originally published at tech.rebounder.jp.

Supabase SECURITY DEFINER RPC Callable by anon: Revoke It

cometa-kaito — Sun, 18 Oct 2026 04:22:31 +0000

The short version

PostgreSQL grants EXECUTE to the PUBLIC role by default the moment CREATE FUNCTION runs. SECURITY DEFINER is the modifier that makes a function run with the privileges of the role that owns it rather than the role that called it. Create a write function with that modifier and leave it without an explicit REVOKE, and it becomes directly callable from the anon (unauthenticated) or authenticated role through Supabase's PostgREST layer.

Even with no GRANT written anywhere, EXECUTE for PUBLIC is there from the start
RLS policies on the table are irrelevant, because a SECURITY DEFINER function runs as the owner
Closing it means writing REVOKE ALL ... FROM PUBLIC explicitly and re-GRANTing only to the roles that need it

What it looks like

We created a function to push records for asynchronous delivery into a table called sync_outbox. Its definition pins search_path. search_path is the schema search path deciding which schema an unqualified object name resolves from inside a function, and pinning it to public is standard practice to stop a caller rewriting it so that a fake same-named object outside public resolves first.

create table if not exists public.sync_outbox (
  id            uuid primary key default gen_random_uuid(),
  kind          text not null,
  ref_id        uuid,
  payload       jsonb not null default '{}'::jsonb,
  status        text not null default 'pending'
                check (status in ('pending','sent','failed','dead')),
  attempts      int  not null default 0,
  -- (omitted)
);

alter table public.sync_outbox enable row level security;
create policy sync_outbox_staff_read on public.sync_outbox
  for select using (public.is_staff());

create or replace function public.enqueue_sync_outbox(p_kind text, p_ref_id uuid, p_payload jsonb)
returns uuid language sql security definer set search_path = public as $$
  insert into public.sync_outbox (kind, ref_id, payload)
  values (p_kind, p_ref_id, coalesce(p_payload, '{}'::jsonb))
  returning id;
$$;

The table's RLS says only "allow SELECT for the staff role". There is no policy anywhere permitting INSERT for anon. The function was written on the premise that only the app's backend (a cron worker) calls it. Pinning search_path was handled, but that guards a different kind of attack and does nothing for the problem here.

But this function is SECURITY DEFINER, and EXECUTE for PUBLIC is granted by default the instant CREATE FUNCTION runs. Supabase's PostgREST automatically exposes functions in the public schema at /rest/v1/rpc/<name>. It connects as anon or authenticated depending on the JWT the caller sends, and both roles inherit PUBLIC's privileges, so any function not explicitly revoked can be called directly by anyone.

That is what the review flagged. The table's RLS correctly narrowed reads to staff, and the function's execute privilege had never been narrowed at all.

Why

Three facts stack up.

① SECURITY DEFINER runs with the function owner's privileges

Not the calling role's privileges but those of the role that owns the function. That much is as specified.

② CREATE FUNCTION grants EXECUTE to PUBLIC by default

Even with no GRANT ever written, the function is callable by anyone the moment it is created. This is the opposite of tables, whose GRANT is closed by default (nobody can touch them without explicit permission): functions are open by default.

③ PostgREST automatically exposes public schema functions as RPCs

anon / authenticated are the connection roles Supabase provides, and they inherit PUBLIC's privileges as they are. With not a single GRANT on the table, one forgotten REVOKE on a SECURITY DEFINER function leaves a write path open that bypasses RLS entirely.

table GRANT        → closed by default → nobody touches it without explicit permission
function EXECUTE   → open by default   → anyone calls it unless explicitly revoked

This asymmetry is the cause of the oversight. Look only at the table and conclude "RLS protects this", and the hole on the function side goes unseen.

Fixing it

Strip the default PUBLIC privilege and re-allow only the roles that need it.

-- Close the SECURITY DEFINER write function to direct calls from anon/authenticated
-- (via PostgREST). Strip the default PUBLIC EXECUTE, allow only the backend (service_role).
revoke all on function public.enqueue_sync_outbox(text, uuid, jsonb) from public;
grant execute on function public.enqueue_sync_outbox(text, uuid, jsonb) to service_role;

REVOKE ALL ... FROM PUBLIC cuts off every inheritance source including anon / authenticated, and GRANT EXECUTE returns it to service_role alone, which actually needs to call it. The function definition itself is unchanged. All that happened is an open door was closed, with no effect on the intended calling path from the backend.

Checking it

Joining pg_proc and pg_roles gives you a function's owner and its execute privileges.

select p.proname, r.rolname as owner, p.proacl
from pg_proc p
join pg_roles r on r.oid = p.proowner
where p.proname = 'enqueue_sync_outbox';

Look for EXECUTE for PUBLIC remaining in proacl (notation like =X/<owner>). Unless this check is run on every new SECURITY DEFINER write function, the same path opens once per function whose revoke was forgotten.

Making it not recur

This fix went in as an addition of revoke / grant to the existing migration file rather than recreating the function. Unless writing REVOKE ALL ... FROM PUBLIC paired with every SECURITY DEFINER function becomes the rule, the next write function added opens the same path.

Write REVOKE / GRANT directly beneath the creation SQL for any SECURITY DEFINER write function, so that adding only one of them is structurally impossible
Include the function's EXECUTE privilege in the same review item as the table's RLS review (on the premise of the asymmetry: tables closed by default, functions open by default)
Verify whether something is anonymously writable by actually querying pg_proc.proacl, not by reading the wording of a policy

However carefully the RLS policies are written, it means nothing if another door — the function's execute privilege — stands open. Another case shaped as an overlooked SECURITY DEFINER is in The function owner and the migration role. That one is about an intended bypass ceasing to work; this one about an unintended bypass working. Both start from the same property: SECURITY DEFINER behaviour is decided by who created the function, not by who called it.

Originally published at tech.rebounder.jp.