## [Bug] Text Input Box Unresponsive and Text Not Displayed Correctly in Fundraising Creation Modal #193

New Issue

2026-05-24T16:14:18Z

enjin2310 commented

2026-05-24 16:14:18 +00:00

🧩 Summary

In the Fundraisers section, the text input box within the “Elige el tipo de recaudación” modal does not allow user interaction. Typed text either fails to appear or is rendered incorrectly, preventing users from proceeding with the fundraiser creation process.

🧪 Steps to Reproduce

Navigate to learn.spikersoft.com/fundraisers.
Click Nueva recaudación.
In the modal step 1. Tipo, attempt to type in the text box.
Observe that the input field does not respond properly — text is either invisible or partially rendered.

✅ Expected Behavior

The text box should:

Accept keyboard input normally.
Display entered text clearly.
Allow users to proceed to the next step after valid input.

❌ Actual Behavior

The input box appears active but does not register keystrokes.
Text is either missing or visually clipped.
The Continuar button remains functional but cannot validate input.

📸 Evidence

The attached screenshot shows the modal with the text field partially filled (“fle”) and rendering issues visible.

🧠 Possible Root Cause

CSS or JavaScript rendering conflict within the modal component.
Input field overlay or z-index issue blocking interaction.
Missing binding between the input element and the state handler.

🔧 Suggested Fix

Inspect the modal’s input component for event listener conflicts.

Ensure proper binding to the input state:

<input
  type="text"
  value={fundraiserType}
  onChange={(e) => setFundraiserType(e.target.value)}
  className="input-field"
/>

### 🧩 Summary In the **Fundraisers** section, the text input box within the **“Elige el tipo de recaudación”** modal does not allow user interaction. Typed text either fails to appear or is rendered incorrectly, preventing users from proceeding with the fundraiser creation process. ### 🧪 Steps to Reproduce 1. Navigate to `learn.spikersoft.com/fundraisers`. 2. Click **Nueva recaudación**. 3. In the modal step **1. Tipo**, attempt to type in the text box. 4. Observe that the input field does not respond properly — text is either invisible or partially rendered. ### ✅ Expected Behavior The text box should: - Accept keyboard input normally. - Display entered text clearly. - Allow users to proceed to the next step after valid input. ### ❌ Actual Behavior - The input box appears active but does not register keystrokes. - Text is either missing or visually clipped. - The **Continuar** button remains functional but cannot validate input. ### 📸 Evidence The attached screenshot shows the modal with the text field partially filled (“fle”) and rendering issues visible. ### 🧠 Possible Root Cause - CSS or JavaScript rendering conflict within the modal component. - Input field overlay or z-index issue blocking interaction. - Missing binding between the input element and the state handler. ### 🔧 Suggested Fix 1. Inspect the modal’s input component for event listener conflicts. 2. Ensure proper binding to the input state: ```js <input type="text" value={fundraiserType} onChange={(e) => setFundraiserType(e.target.value)} className="input-field" />

Screenshot 2026-05-24 121305.png

134 KiB

spikerj commented

2026-06-08 15:32:22 +00:00

Triage note: I can't reproduce this in the current build. The "Elige el tipo de recaudación" (step 1 / Tipo) screen was redesigned and no longer contains a free-text input — the fundraiser type is now chosen via selectable radio cards (Product Resale / Bake Sale / Service-Based / Custom), so there is no text box there to be unresponsive. This appears to have been resolved by the redesign since the report (reported against v2026.05.17a).

Leaving open for re-verification: please confirm against the latest deploy. If you were instead referring to the text inputs in the Items step (item name / cost), those are addressed in PR #14 (#194 / #195).

Triage note: I can't reproduce this in the current build. The "Elige el tipo de recaudación" (step 1 / Tipo) screen was redesigned and no longer contains a free-text input — the fundraiser type is now chosen via selectable radio cards (Product Resale / Bake Sale / Service-Based / Custom), so there is no text box there to be unresponsive. This appears to have been resolved by the redesign since the report (reported against v2026.05.17a). Leaving open for re-verification: please confirm against the latest deploy. If you were instead referring to the text inputs in the **Items** step (item name / cost), those are addressed in PR #14 (#194 / #195).

spikerj referenced this issue

2026-06-08 15:55:33 +00:00

Bug: Calendar section - Event creation form fields unresponsive #181

spikerj referenced this issue

2026-06-16 05:17:49 +00:00

[Bug] Minecraft (wasm-voxel) leaks global mouse/keyboard listeners that break input app-wide after leaving the game #228

spikerj commented

2026-06-16 13:59:50 +00:00

Root cause found and fixed. The modal's text input was wired correctly; the input was being swallowed by an app-wide listener leak from the games. The Minecraft (wasm-voxel) engine leaked a global document mousedown (with preventDefault) and global keydown/keyup handlers that were never removed when leaving the game, so for the rest of the SPA session (until reload) clicking into / typing in the “Elige el tipo de recaudación” field did nothing. The leaked game listeners are now torn down on destroy in spikersoft-angular PR #62 (merged to master), with the related game keydown-capture leaks fixed in PR #61 (merged). Closing — please reopen if it still reproduces on the latest deploy (noting whether a game was opened earlier in the session helps).

Root cause found and fixed. The modal's text input was wired correctly; the input was being swallowed by an app-wide listener leak from the games. The Minecraft (`wasm-voxel`) engine leaked a global `document` `mousedown` (with `preventDefault`) and global `keydown`/`keyup` handlers that were never removed when leaving the game, so for the rest of the SPA session (until reload) clicking into / typing in the “Elige el tipo de recaudación” field did nothing. The leaked game listeners are now torn down on destroy in spikersoft-angular PR #62 (merged to `master`), with the related game keydown-capture leaks fixed in PR #61 (merged). Closing — please reopen if it still reproduces on the latest deploy (noting whether a game was opened earlier in the session helps).

spikerj closed this issue

2026-06-16 13:59:59 +00:00

spikerj referenced this issue

2026-07-09 01:25:22 +00:00

backend: expand integration coverage — art pipe messaging, safety RPC, GPU leases, quiz path #465

spikerj referenced this issue

2026-07-16 03:27:08 +00:00

[Bug][Frontend][Backend] C# playground lessons don't switch to Spanish on language toggle — In-Browser (WASM) path is English-only by construction #608

Sign in to join this conversation.