lhumina_code/hero_os

Fork 0

UI: Create/Submit buttons remain enabled with empty required fields — silent no-op across multiple islands #68

New issue

Closed

opened 2026-04-16 14:22:33 +00:00 by rawdaGastan · 4 comments

rawdaGastan commented

2026-04-16 14:22:33 +00:00

Member

Problem

Across several islands, the primary Create/Submit button is not disabled when required fields are empty. Clicking it with empty required fields does nothing: no validation message, no focus-to-field, no error banner. The user sees zero response and is left guessing. This pattern was fixed for Contacts in closed #50 but has re-emerged in multiple islands on the current dev build.

Reproductions (local build via hero_router at `http://127.0.0.1:9988/hero_os/ui/...`)

Island	Form	Required field(s)	Observed with empty fields
Core → Contexts → "+ New Context"	"Create New Context"	Display Name, Identifier	Button enabled, click = silent no-op
Communication → Conference → Create Room	inline "Create Room"	Room name	Button enabled, click = silent no-op
Projects → Tasks → Add Task	"New Task"	Task Title	Button enabled, click = silent no-op

(Filled submissions succeed or produce their real RPC error — this issue is specifically about the empty-fields path.)

#50 [closed] — UI: Contacts form validation — Create button not disabled when required fields empty. Same pattern, fixed for Contacts only.
#52 [closed] — UI: New Chat 'Create Chat' button not disabled when no participants selected. Related.

Expected

Either:

Disable the submit button while any required field is empty, or
On click with empty required fields, show an inline validation message and focus the first empty required field.

Preferably the first — consistent with the Contacts fix from #50.

Repo rationale

Validation lives in the Dioxus form components in hero_os, not the backend.

### Problem Across several islands, the primary Create/Submit button is not disabled when required fields are empty. Clicking it with empty required fields does nothing: no validation message, no focus-to-field, no error banner. The user sees zero response and is left guessing. This pattern was fixed for Contacts in closed #50 but has re-emerged in multiple islands on the current dev build. ### Reproductions (local build via hero_router at `http://127.0.0.1:9988/hero_os/ui/...`) | Island | Form | Required field(s) | Observed with empty fields | |---|---|---|---| | Core → Contexts → "+ New Context" | "Create New Context" | Display Name, Identifier | Button enabled, click = silent no-op | | Communication → Conference → Create Room | inline "Create Room" | Room name | Button enabled, click = silent no-op | | Projects → Tasks → Add Task | "New Task" | Task Title | Button enabled, click = silent no-op | (Filled submissions succeed or produce their real RPC error — this issue is specifically about the empty-fields path.) ### Related existing issues - **#50 [closed]** — UI: Contacts form validation — Create button not disabled when required fields empty. Same pattern, fixed for Contacts only. - **#52 [closed]** — UI: New Chat 'Create Chat' button not disabled when no participants selected. Related. ### Expected Either: - Disable the submit button while any required field is empty, **or** - On click with empty required fields, show an inline validation message and focus the first empty required field. Preferably the first — consistent with the Contacts fix from #50. ### Repo rationale Validation lives in the Dioxus form components in hero_os, not the backend.

rawdaGastan self-assigned this

2026-04-20 10:30:41 +00:00

rawdaGastan added this to the ACTIVE project

2026-04-20 10:30:43 +00:00

rawdaGastan commented

2026-04-20 13:34:28 +00:00

Author

Member

Implementation Spec for Issue #68

Note on repo scope

The issue is filed here on hero_os, but the failing forms are Dioxus islands that live in the sibling repo lhumina_code/hero_archipelagos. The fix will land in hero_archipelagos; this issue will be closed by a PR there, and this comment will link to it.

Objective

Disable the primary submit button across three islands (Contexts, Conference/Room, Tasks) whenever required fields are empty or whitespace-only, mirroring the Contacts form pattern from #50.

Reference pattern (from #50 Contacts fix)

File: archipelagos/contacts/src/islands/contact_form.rs

can_submit derivation (L48):

let can_submit = !name.read().is_empty() && !public_key.read().is_empty() && !props.saving;

Submit button RSX (L222-239):

Button {
    variant: if can_submit { ButtonVariant::Primary } else { ButtonVariant::Secondary },
    disabled: !can_submit,
    loading: props.saving,
    onclick: handle_submit,
    // ...
}

Shape: one can_submit: bool derived from !signal.read().is_empty() clauses ANDed together, passed as disabled: !can_submit to the shared hero_archipelagos_core::Button. The onclick handler also early-returns when !can_submit as defense-in-depth. The shared Button never emits the HTML disabled attribute — it applies the hero-btn-disabled CSS class and gates onclick internally, so passing disabled: !can_submit is the correct visual and behavioral switch (core/src/components/button.rs L119-138).

Requirements

All three broken forms must disable their primary submit button when required fields are empty.
"Whitespace-only counts as empty" — use trim().is_empty() rather than is_empty().
Must use disabled: !can_submit on the shared Button component, not an ad-hoc pointer-events: none div wrapper.
Each step touches a different file so they can be implemented in parallel.
cargo check must still pass.

Files to modify

archipelagos/system/contexts/src/views/create_form.rs (L47-48 and L207-242) — replace div-wrapper visual gating with real disabled prop; tighten can_submit with trim().
archipelagos/communication/room/src/views/room_card.rs (L111) — tighten can_save with trim() (button already uses disabled: !can_save at L374-399).
archipelagos/productivity/tasks/src/views/new_task_view.rs (L31) — tighten can_submit with trim() (button already uses disabled: !can_submit at L177-185).

Implementation plan

Step 1 — Contexts "Create Context" button

File: archipelagos/system/contexts/src/views/create_form.rs

1a. Derivation (L47-48)

Current:

let is_duplicate = props.existing_names.contains(&*name.read());
let can_submit = !name.read().is_empty() && !title.read().is_empty() && !is_duplicate;

Replace with:

let is_duplicate = props.existing_names.contains(&*name.read());
let can_submit = !name.read().trim().is_empty()
    && !title.read().trim().is_empty()
    && !is_duplicate;

1b. Submit button (L207-242)

Current — a div wrapper fakes disablement with pointer-events: none, which is the root cause of the "silent no-op" (clicks are swallowed with zero feedback):

div {
    style: if can_submit {
        "opacity: 1; pointer-events: auto;"
    } else {
        "opacity: 0.5; pointer-events: none;"
    },
    Button {
        variant: ButtonVariant::Success,
        onclick: move |_| {
            if can_submit { /* ...create... */ }
        },
        "Create Context"
    }
}

Replace with (mirror Contacts pattern):

Button {
    variant: if can_submit { ButtonVariant::Success } else { ButtonVariant::Secondary },
    disabled: !can_submit,
    onclick: move |_| {
        if !can_submit { return; }
        /* ...create... */
    },
    "Create Context"
}

Dependencies: none.

Step 2 — Conference "Create Room" button

File: archipelagos/communication/room/src/views/room_card.rs

The button at L374-399 already uses disabled: !can_save. Only the derivation needs tightening.

Current (L111):

let can_save = !name.read().is_empty();

Replace with:

let can_save = !name.read().trim().is_empty();

Dependencies: none (independent of Step 1 and Step 3).

Step 3 — Tasks "Create Task" button

File: archipelagos/productivity/tasks/src/views/new_task_view.rs

The button at L177-185 already uses disabled: !can_submit. Only the derivation needs tightening.

Current (L31):

let can_submit = !title.read().is_empty() && !*is_submitting.read();

Replace with:

let can_submit = !title.read().trim().is_empty() && !*is_submitting.read();

Dependencies: none (independent of Steps 1 and 2).

Acceptance criteria

Contexts: "Create Context" is disabled while Display Name or Identifier is empty/whitespace-only; clicking a disabled button has no side effects. No pointer-events: none div wrapper remains — disabled prop is on the Button directly.
Conference: "Create Room" is disabled while Room name is empty/whitespace-only.
Tasks: header "Create Task" button in the New Task view is disabled while Task Title is empty/whitespace-only.
All three forms derive a single bool and pass disabled: !<bool> to the shared Button, matching the Contacts reference pattern.
State is reactive — enables as soon as the user types a non-whitespace character, disables again when cleared.
cargo check passes for the workspace.

Notes

Contexts is the clearest case of "silent no-op": can_submit was already computed, but the author tried to fake disablement with pointer-events: none on a wrapping div. The click is swallowed by the CSS gate with no visible response. Moving to the real disabled prop fixes this and aligns with the rest of the codebase.
Room and Tasks already wire disabled: !can_* correctly on the Button, but use bare is_empty() — so a single space character enables the button and lets whitespace-only values through. One-line fix per file.
The reference Contacts fix at contact_form.rs L48 also uses bare is_empty(); this spec tightens beyond the original to match this issue's acceptance criteria ("whitespace-only counts as empty").
Tasks has a secondary internal TaskForm component (productivity/tasks/src/views/task_form.rs L35) with the same pattern. It is not the flow reached by "Tasks → Add Task" in the current build, so it is out of scope here but flagged for a follow-up.
Other buttons (Cancel, etc.) remain unchanged — only primary Create/Submit buttons are gated.

## Implementation Spec for Issue #68 ### Note on repo scope The issue is filed here on `hero_os`, but the failing forms are Dioxus islands that live in the sibling repo `lhumina_code/hero_archipelagos`. The fix will land in `hero_archipelagos`; this issue will be closed by a PR there, and this comment will link to it. ### Objective Disable the primary submit button across three islands (Contexts, Conference/Room, Tasks) whenever required fields are empty or whitespace-only, mirroring the Contacts form pattern from #50. ### Reference pattern (from #50 Contacts fix) File: `archipelagos/contacts/src/islands/contact_form.rs` `can_submit` derivation (L48): ```rust let can_submit = !name.read().is_empty() && !public_key.read().is_empty() && !props.saving; ``` Submit button RSX (L222-239): ```rust Button { variant: if can_submit { ButtonVariant::Primary } else { ButtonVariant::Secondary }, disabled: !can_submit, loading: props.saving, onclick: handle_submit, // ... } ``` Shape: one `can_submit: bool` derived from `!signal.read().is_empty()` clauses ANDed together, passed as `disabled: !can_submit` to the shared `hero_archipelagos_core::Button`. The `onclick` handler also early-returns when `!can_submit` as defense-in-depth. The shared `Button` never emits the HTML `disabled` attribute — it applies the `hero-btn-disabled` CSS class and gates `onclick` internally, so passing `disabled: !can_submit` is the correct visual *and* behavioral switch (`core/src/components/button.rs` L119-138). ### Requirements - All three broken forms must disable their primary submit button when required fields are empty. - "Whitespace-only counts as empty" — use `trim().is_empty()` rather than `is_empty()`. - Must use `disabled: !can_submit` on the shared `Button` component, not an ad-hoc `pointer-events: none` div wrapper. - Each step touches a different file so they can be implemented in parallel. - `cargo check` must still pass. ### Files to modify - `archipelagos/system/contexts/src/views/create_form.rs` (L47-48 and L207-242) — replace div-wrapper visual gating with real `disabled` prop; tighten `can_submit` with `trim()`. - `archipelagos/communication/room/src/views/room_card.rs` (L111) — tighten `can_save` with `trim()` (button already uses `disabled: !can_save` at L374-399). - `archipelagos/productivity/tasks/src/views/new_task_view.rs` (L31) — tighten `can_submit` with `trim()` (button already uses `disabled: !can_submit` at L177-185). ### Implementation plan #### Step 1 — Contexts "Create Context" button File: `archipelagos/system/contexts/src/views/create_form.rs` **1a. Derivation (L47-48)** Current: ```rust let is_duplicate = props.existing_names.contains(&*name.read()); let can_submit = !name.read().is_empty() && !title.read().is_empty() && !is_duplicate; ``` Replace with: ```rust let is_duplicate = props.existing_names.contains(&*name.read()); let can_submit = !name.read().trim().is_empty() && !title.read().trim().is_empty() && !is_duplicate; ``` **1b. Submit button (L207-242)** Current — a div wrapper fakes disablement with `pointer-events: none`, which is the root cause of the "silent no-op" (clicks are swallowed with zero feedback): ```rust div { style: if can_submit { "opacity: 1; pointer-events: auto;" } else { "opacity: 0.5; pointer-events: none;" }, Button { variant: ButtonVariant::Success, onclick: move |_| { if can_submit { /* ...create... */ } }, "Create Context" } } ``` Replace with (mirror Contacts pattern): ```rust Button { variant: if can_submit { ButtonVariant::Success } else { ButtonVariant::Secondary }, disabled: !can_submit, onclick: move |_| { if !can_submit { return; } /* ...create... */ }, "Create Context" } ``` Dependencies: none. #### Step 2 — Conference "Create Room" button File: `archipelagos/communication/room/src/views/room_card.rs` The button at L374-399 already uses `disabled: !can_save`. Only the derivation needs tightening. Current (L111): ```rust let can_save = !name.read().is_empty(); ``` Replace with: ```rust let can_save = !name.read().trim().is_empty(); ``` Dependencies: none (independent of Step 1 and Step 3). #### Step 3 — Tasks "Create Task" button File: `archipelagos/productivity/tasks/src/views/new_task_view.rs` The button at L177-185 already uses `disabled: !can_submit`. Only the derivation needs tightening. Current (L31): ```rust let can_submit = !title.read().is_empty() && !*is_submitting.read(); ``` Replace with: ```rust let can_submit = !title.read().trim().is_empty() && !*is_submitting.read(); ``` Dependencies: none (independent of Steps 1 and 2). ### Acceptance criteria - [ ] Contexts: "Create Context" is disabled while Display Name or Identifier is empty/whitespace-only; clicking a disabled button has no side effects. No `pointer-events: none` div wrapper remains — `disabled` prop is on the `Button` directly. - [ ] Conference: "Create Room" is disabled while Room name is empty/whitespace-only. - [ ] Tasks: header "Create Task" button in the New Task view is disabled while Task Title is empty/whitespace-only. - [ ] All three forms derive a single bool and pass `disabled: !<bool>` to the shared `Button`, matching the Contacts reference pattern. - [ ] State is reactive — enables as soon as the user types a non-whitespace character, disables again when cleared. - [ ] `cargo check` passes for the workspace. ### Notes - **Contexts** is the clearest case of "silent no-op": `can_submit` was already computed, but the author tried to fake disablement with `pointer-events: none` on a wrapping div. The click is swallowed by the CSS gate with no visible response. Moving to the real `disabled` prop fixes this and aligns with the rest of the codebase. - **Room** and **Tasks** already wire `disabled: !can_*` correctly on the `Button`, but use bare `is_empty()` — so a single space character enables the button and lets whitespace-only values through. One-line fix per file. - The reference Contacts fix at `contact_form.rs` L48 also uses bare `is_empty()`; this spec tightens beyond the original to match this issue's acceptance criteria ("whitespace-only counts as empty"). - Tasks has a secondary internal `TaskForm` component (`productivity/tasks/src/views/task_form.rs` L35) with the same pattern. It is not the flow reached by "Tasks → Add Task" in the current build, so it is out of scope here but flagged for a follow-up. - Other buttons (Cancel, etc.) remain unchanged — only primary Create/Submit buttons are gated.

rawdaGastan commented

2026-04-20 13:51:25 +00:00

Author

Member

Build & Test Results

Branch: development_ui_required_field_validation (in lhumina_code/hero_archipelagos)

Files changed:

archipelagos/system/contexts/src/views/create_form.rs
archipelagos/communication/room/src/views/room_card.rs
archipelagos/productivity/tasks/src/views/new_task_view.rs

cargo check --workspace: fail (pre-existing, unrelated to this refactor)

The workspace-level check fails in two crates that are not touched by this branch:

hero_archipelagos_knowledge: 9 errors (unresolved hero_osis_sdk module, type inference failures on EmbedderClient / BucketListResult / CreateBucketResult)
hero_archipelagos_messaging: 2 errors (missing method conversationservice_list_messages on CommunicationClient, suggested conversation_list; downstream type-inference error)

Error tail:

error[E0433]: failed to resolve: use of unresolved module or unlinked crate `hero_osis_sdk`
 --> archipelagos/intelligence/knowledge/src/island.rs:5:5
  |
5 | use hero_osis_sdk::embedder::KnowledgeBucket;
  |     ^^^^^^^^^^^^^ use of unresolved module or unlinked crate `hero_osis_sdk`

error[E0599]: no method named `conversationservice_list_messages` found for struct `CommunicationClient` in the current scope
   --> archipelagos/messaging/src/services/messaging_service.rs:105:10
    |
104 | /     client
105 | |         .conversationservice_list_messages(conversation_sid.to_string())
    | |_________-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
help: there is a method `conversation_list` with a similar name, but with different arguments

error: could not compile `hero_archipelagos_knowledge` (lib) due to 9 previous errors
error: could not compile `hero_archipelagos_messaging` (lib) due to 2 previous errors

All three crates touched by this branch pass cargo check individually:

cargo check -p hero_archipelagos_contexts: pass
cargo check -p hero_archipelagos_room: pass
cargo check -p hero_archipelagos_tasks: pass

Per-crate cargo test:

hero_archipelagos_contexts: no-tests (0 passed, 0 failed; 0 doc-tests)
hero_archipelagos_room: no-tests (0 passed, 0 failed; 0 doc-tests)
hero_archipelagos_tasks: no-tests (0 passed, 0 failed; 0 doc-tests)

The refactor to the three view modules compiles cleanly and does not introduce any regressions in the touched crates. The workspace-level failures are upstream SDK drift (hero_osis_sdk / CommunicationClient API changes) and should be addressed separately.

## Build & Test Results **Branch:** `development_ui_required_field_validation` (in `lhumina_code/hero_archipelagos`) **Files changed:** - `archipelagos/system/contexts/src/views/create_form.rs` - `archipelagos/communication/room/src/views/room_card.rs` - `archipelagos/productivity/tasks/src/views/new_task_view.rs` **`cargo check --workspace`:** fail (pre-existing, unrelated to this refactor) The workspace-level check fails in two crates that are not touched by this branch: - `hero_archipelagos_knowledge`: 9 errors (unresolved `hero_osis_sdk` module, type inference failures on `EmbedderClient` / `BucketListResult` / `CreateBucketResult`) - `hero_archipelagos_messaging`: 2 errors (missing method `conversationservice_list_messages` on `CommunicationClient`, suggested `conversation_list`; downstream type-inference error) Error tail: ``` error[E0433]: failed to resolve: use of unresolved module or unlinked crate `hero_osis_sdk` --> archipelagos/intelligence/knowledge/src/island.rs:5:5 | 5 | use hero_osis_sdk::embedder::KnowledgeBucket; | ^^^^^^^^^^^^^ use of unresolved module or unlinked crate `hero_osis_sdk` error[E0599]: no method named `conversationservice_list_messages` found for struct `CommunicationClient` in the current scope --> archipelagos/messaging/src/services/messaging_service.rs:105:10 | 104 | / client 105 | | .conversationservice_list_messages(conversation_sid.to_string()) | |_________-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | help: there is a method `conversation_list` with a similar name, but with different arguments error: could not compile `hero_archipelagos_knowledge` (lib) due to 9 previous errors error: could not compile `hero_archipelagos_messaging` (lib) due to 2 previous errors ``` All three crates touched by this branch pass `cargo check` individually: - `cargo check -p hero_archipelagos_contexts`: pass - `cargo check -p hero_archipelagos_room`: pass - `cargo check -p hero_archipelagos_tasks`: pass **Per-crate `cargo test`:** - `hero_archipelagos_contexts`: no-tests (0 passed, 0 failed; 0 doc-tests) - `hero_archipelagos_room`: no-tests (0 passed, 0 failed; 0 doc-tests) - `hero_archipelagos_tasks`: no-tests (0 passed, 0 failed; 0 doc-tests) The refactor to the three view modules compiles cleanly and does not introduce any regressions in the touched crates. The workspace-level failures are upstream SDK drift (`hero_osis_sdk` / `CommunicationClient` API changes) and should be addressed separately.

rawdaGastan commented

2026-04-20 14:43:37 +00:00

Author

Member

Implementation Summary

Fix landed on branch development_ui_required_field_validation in sibling repo lhumina_code/hero_archipelagos.

Changes

Three files, each gating the primary submit button via the shared hero_archipelagos_core::Button disabled prop and using trim().is_empty() so whitespace-only counts as empty:

archipelagos/system/contexts/src/views/create_form.rs — removed the pointer-events: none div wrapper that was silently swallowing clicks; added disabled: !can_submit directly on the Button; switched variant to Secondary when disabled; inverted the inner onclick guard to an early return.
archipelagos/communication/room/src/views/room_card.rs — tightened can_save with trim() (button already passed disabled: !can_save).
archipelagos/productivity/tasks/src/views/new_task_view.rs — tightened can_submit with trim() (button already passed disabled: !can_submit).

Build & tests

cargo check passes for all three touched crates (hero_archipelagos_contexts, hero_archipelagos_room, hero_archipelagos_tasks).
cargo test for the three crates: no unit tests defined; all pass vacuously.
Workspace-level cargo check has pre-existing, unrelated compile errors in hero_archipelagos_knowledge (unresolved hero_osis_sdk module) and hero_archipelagos_messaging (upstream SDK drift — conversationservice_list_messages renamed). Neither is touched by this branch.

Live browser verification (headless Chromium via hero_browser MCP, then local Chrome)

For each form: empty required fields, whitespace-only required fields, valid content, and cleared-again states were checked.

Contexts / Create Context: verified. Empty or whitespace-only fields → button has hero-btn-disabled class (opacity 0.5, cursor: not-allowed, pointer-events: none); click does not register; no pointer-events: none wrapper div remains. Valid fields → button switches to Success variant and is fully clickable. Reactive in both directions.
Tasks / Create Task (header button in NewTaskView): verified. Same four-state behaviour.
Conference / Create Room: source-verified only — the current hero_os_app web feature does not compile island-room; the Conferences island embeds a hero_livekit iframe instead. The fix is in place in room_card.rs and will activate in any build that includes island-room or renders the room card standalone.

Notes

The hero_archipelagos_core::Button disabled behaviour relies on the .hero-btn-disabled CSS rule added in the recent pull (core/src/island.css L128). hero_os_app embeds this via hero_archipelagos_core::ISLAND_CSS. A stale WASM build cached from before that CSS arrived must be cleanly rebuilt once to pick it up.
Reference pattern mirrors the #50 Contacts fix at archipelagos/contacts/src/islands/contact_form.rs.

PR link will follow in the next comment.

## Implementation Summary Fix landed on branch `development_ui_required_field_validation` in sibling repo `lhumina_code/hero_archipelagos`. ### Changes Three files, each gating the primary submit button via the shared `hero_archipelagos_core::Button` `disabled` prop and using `trim().is_empty()` so whitespace-only counts as empty: - `archipelagos/system/contexts/src/views/create_form.rs` — removed the `pointer-events: none` div wrapper that was silently swallowing clicks; added `disabled: !can_submit` directly on the `Button`; switched variant to `Secondary` when disabled; inverted the inner `onclick` guard to an early return. - `archipelagos/communication/room/src/views/room_card.rs` — tightened `can_save` with `trim()` (button already passed `disabled: !can_save`). - `archipelagos/productivity/tasks/src/views/new_task_view.rs` — tightened `can_submit` with `trim()` (button already passed `disabled: !can_submit`). ### Build & tests - `cargo check` passes for all three touched crates (`hero_archipelagos_contexts`, `hero_archipelagos_room`, `hero_archipelagos_tasks`). - `cargo test` for the three crates: no unit tests defined; all pass vacuously. - Workspace-level `cargo check` has pre-existing, unrelated compile errors in `hero_archipelagos_knowledge` (unresolved `hero_osis_sdk` module) and `hero_archipelagos_messaging` (upstream SDK drift — `conversationservice_list_messages` renamed). Neither is touched by this branch. ### Live browser verification (headless Chromium via hero_browser MCP, then local Chrome) For each form: empty required fields, whitespace-only required fields, valid content, and cleared-again states were checked. - **Contexts / Create Context**: verified. Empty or whitespace-only fields → button has `hero-btn-disabled` class (opacity 0.5, `cursor: not-allowed`, `pointer-events: none`); click does not register; no `pointer-events: none` wrapper div remains. Valid fields → button switches to `Success` variant and is fully clickable. Reactive in both directions. - **Tasks / Create Task** (header button in `NewTaskView`): verified. Same four-state behaviour. - **Conference / Create Room**: source-verified only — the current `hero_os_app` `web` feature does not compile `island-room`; the Conferences island embeds a `hero_livekit` iframe instead. The fix is in place in `room_card.rs` and will activate in any build that includes `island-room` or renders the room card standalone. ### Notes - The `hero_archipelagos_core::Button` disabled behaviour relies on the `.hero-btn-disabled` CSS rule added in the recent pull (`core/src/island.css` L128). `hero_os_app` embeds this via `hero_archipelagos_core::ISLAND_CSS`. A stale WASM build cached from before that CSS arrived must be cleanly rebuilt once to pick it up. - Reference pattern mirrors the `#50` Contacts fix at `archipelagos/contacts/src/islands/contact_form.rs`. PR link will follow in the next comment.

rawdaGastan referenced this issue from a commit

2026-04-20 14:44:24 +00:00

fix(ui): disable Create/Submit buttons for empty required fields

rawdaGastan referenced this issue from lhumina_code/hero_archipelagos

2026-04-20 14:44:46 +00:00

fix(ui): disable Create/Submit buttons for empty required fields #93

rawdaGastan commented

2026-04-20 14:45:17 +00:00

Author

Member

Pull request opened: lhumina_code/hero_archipelagos#93

This PR implements the Create/Submit button disable behaviour discussed in this issue across the three affected islands (Contexts, Conference/Room, Tasks).

Pull request opened: https://forge.ourworld.tf/lhumina_code/hero_archipelagos/pulls/93 This PR implements the Create/Submit button disable behaviour discussed in this issue across the three affected islands (Contexts, Conference/Room, Tasks).