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

New Issue

2026-05-22T18:43:14Z

Zhekrom commented

2026-05-22 18:43:14 +00:00

Title: Bug: Calendar section - Event creation form fields unresponsive
Severity: High
Mode: Calendar
Lesson ID / File: Calendar section - Event creation
Environment: Browser (specify version), OS (specify version)
Date/Time: 2026-05-22

Source Code

(Not applicable � UI/interaction issue)

Steps to Reproduce

1. Navigate to the Calendar section.
2. Click on a specific day to add an event.
3. Try to type in the event fields.
4. Try to select a location or interact with any other field.

Expected Output

The event creation form should be fully interactive: text fields should accept input, dropdowns should be selectable, and all fields should respond to user interaction.

Actual Output

None of the event creation fields respond to interaction. The user cannot type, select a location, or interact with any form element. The form appears visually but is completely inert.

Suggested Priority

High � The calendar event creation feature is completely non-functional. Users cannot create events.

Additional Notes

Similar to the AI assistant issue (#176) where UI components render visually but have no event handlers attached. Likely the same root cause: click/input handlers not wired up.

Title: Bug: Calendar section - Event creation form fields unresponsive Severity: High Mode: Calendar Lesson ID / File: Calendar section - Event creation Environment: Browser (specify version), OS (specify version) Date/Time: 2026-05-22 Source Code (Not applicable � UI/interaction issue) Steps to Reproduce 1. Navigate to the Calendar section. 2. Click on a specific day to add an event. 3. Try to type in the event fields. 4. Try to select a location or interact with any other field. Expected Output The event creation form should be fully interactive: text fields should accept input, dropdowns should be selectable, and all fields should respond to user interaction. Actual Output None of the event creation fields respond to interaction. The user cannot type, select a location, or interact with any form element. The form appears visually but is completely inert. Suggested Priority High � The calendar event creation feature is completely non-functional. Users cannot create events. Additional Notes Similar to the AI assistant issue (#176) where UI components render visually but have no event handlers attached. Likely the same root cause: click/input handlers not wired up.

Screenshot 2026-05-22 144412.png

99 KiB

spikerj commented

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

Triage update: I went through the calendar event-creation flow and could not find a code defect that would make the fields inert.

What I verified in the current build:

Clicking a day opens the modal with mode: "create", and the form is only disabled in view mode — in create mode every control is enabled.
The form uses standard reactive-forms formControlName bindings (title, description, location, date/time, color), so the inputs are wired correctly (this differs from the AI assistant in #176, which had a genuine [(ngModel)]-on-signal binding bug — now fixed in PR #15).
The dialog/overlay z-index scale is correct (cdk-overlay-container 2000 / mat-mdc-dialog-container 2100), and there's no global pointer-events: none or stacking rule covering the dialog.
There is a passing unit test for create-mode form initialization.

Given the report was filed against v2026.05.17a, this may already be resolved (similar to #193). Could you re-verify against the latest deploy and, if it still reproduces, add the browser + OS and whether it happens on a fresh reload vs. after navigating within the app? A console screenshot at the moment of clicking a field would help pinpoint whether an overlay is intercepting clicks. Leaving open pending that info.

Triage update: I went through the calendar event-creation flow and could not find a code defect that would make the fields inert. What I verified in the current build: - Clicking a day opens the modal with `mode: "create"`, and the form is only disabled in `view` mode — in create mode every control is enabled. - The form uses standard reactive-forms `formControlName` bindings (title, description, location, date/time, color), so the inputs are wired correctly (this differs from the AI assistant in #176, which had a genuine `[(ngModel)]`-on-signal binding bug — now fixed in PR #15). - The dialog/overlay z-index scale is correct (`cdk-overlay-container` 2000 / `mat-mdc-dialog-container` 2100), and there's no global `pointer-events: none` or stacking rule covering the dialog. - There is a passing unit test for create-mode form initialization. Given the report was filed against v2026.05.17a, this may already be resolved (similar to #193). Could you re-verify against the latest deploy and, if it still reproduces, add the **browser + OS** and whether it happens on a fresh reload vs. after navigating within the app? A console screenshot at the moment of clicking a field would help pinpoint whether an overlay is intercepting clicks. Leaving open pending that info.

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:45 +00:00

Root cause found and fixed. The form fields were correctly wired — the problem was an app-wide input-capture leak from the games, not missing handlers. The Minecraft (wasm-voxel) engine leaked a global document mousedown listener that called preventDefault() on every press; preventDefault on mousedown suppresses the browser's default focus, so after a game session (which persists for the whole SPA session until a reload) clicking into a calendar event field no longer focused it and keystrokes went nowhere — the form looked completely inert. The leaked global game listeners are now torn down on destroy in spikersoft-angular PR #62 (merged to master), and the related game keydown-capture leaks were fixed in PR #61 (merged). Closing — please reopen if you can still reproduce on the latest deploy (it helps to note whether a game/Minecraft was opened earlier in the same session).

Root cause found and fixed. The form fields were correctly wired — the problem was an app-wide input-capture leak from the games, not missing handlers. The Minecraft (`wasm-voxel`) engine leaked a global `document` `mousedown` listener that called `preventDefault()` on every press; `preventDefault` on `mousedown` suppresses the browser's default focus, so after a game session (which persists for the whole SPA session until a reload) clicking into a calendar event field no longer focused it and keystrokes went nowhere — the form looked completely inert. The leaked global game listeners are now torn down on destroy in spikersoft-angular PR #62 (merged to `master`), and the related game keydown-capture leaks were fixed in PR #61 (merged). Closing — please reopen if you can still reproduce on the latest deploy (it helps to note whether a game/Minecraft was opened earlier in the same session).

spikerj closed this issue

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

spikerj referenced this issue

2026-07-07 23:37:52 +00:00

[Art Studio] No text→3D capability — add Shap-E / Hunyuan3D text_to_3d modeling path (#378/#446) #456

spikerj referenced this issue

2026-07-08 01:28:45 +00:00

[Art Studio] No text→3D capability — add Shap-E / Hunyuan3D text_to_3d modeling path (#378/#446) #456

spikerj referenced this issue

2026-07-08 22:48:37 +00:00

[Art Studio] No text→3D capability — add Shap-E / Hunyuan3D text_to_3d modeling path (#378/#446) #456

spikerj referenced this issue