# [Bug] Inconsistent Behavior of Quick Actions Button in Geography Explorer #1119

New Issue

2026-08-27T23:23:34Z

enjin2310 commented

2026-08-27 23:23:34 +00:00

Summary

The Quick Actions button located at the bottom-right corner accross of the SpikerSoft Site interface exhibits inconsistent behavior when clicked repeatedly in short intervals. The submenu sometimes fails to appear or disappear correctly, leading to unpredictable UI responses.

Issue Description

When the user clicks the Quick Actions button multiple times in rapid succession (approximately every half second), the submenu does not behave as expected. In some instances, the submenu remains visible and does not hide when clicked again; in others, it fails to appear entirely. This inconsistent toggle behavior suggests a race condition or improper state handling in the button’s event logic.

Environment

Property	Value
Application	SpikerSoft Learn
Module	SpikerSoft App
Environment	Production
Browser	Firefox
Operating System	Windows 11
Version	v2026.08.27e
Device	Desktop

Preconditions

User must be logged in and have access to the SpikerSoft interface.

Steps to Reproduce

Log in to the SpikerSoft platform.
Navigate to Learn > Geography Explorer.
Locate the Quick Actions button at the bottom-right corner.
Click the button repeatedly at intervals of ~0.5 seconds.
Observe the submenu’s visibility behavior.

Expected Result

The submenu should consistently toggle between visible and hidden states with each click, regardless of click frequency.

Actual Result

The submenu occasionally fails to appear.
In other cases, it remains visible and does not hide when clicked again.
The button’s visual state does not always reflect the submenu’s actual visibility.

Evidence

The screenshot shows the Geography Explorer interface with the Quick Actions button visible in the bottom-right corner.
The tooltip “Show quick actions” confirms the button’s intended functionality.
Repeated clicks cause inconsistent submenu behavior.

Impact

Reduces UI reliability and user confidence.
Interrupts workflow when users attempt to access quick actions rapidly.
Suggests potential asynchronous state conflicts in the button’s event handler.

Frequency

Intermittent (triggered by rapid clicks)

Reproducibility

80–100%

Severity

Medium

Notes

The issue may be caused by:

Missing debounce or throttling logic in the click event handler.
Improper synchronization between submenu visibility state and button animation.
It is recommended to implement a short debounce delay or state lock to ensure consistent toggle behavior.

## Summary The **Quick Actions** button located at the bottom-right corner accross of the **SpikerSoft Site** interface exhibits inconsistent behavior when clicked repeatedly in short intervals. The submenu sometimes fails to appear or disappear correctly, leading to unpredictable UI responses. ## Issue Description When the user clicks the **Quick Actions** button multiple times in rapid succession (approximately every half second), the submenu does not behave as expected. In some instances, the submenu remains visible and does not hide when clicked again; in others, it fails to appear entirely. This inconsistent toggle behavior suggests a race condition or improper state handling in the button’s event logic. ## Environment | Property | Value | |-----------|--------| | Application | SpikerSoft Learn | | Module | SpikerSoft App | | Environment | Production | | Browser | Firefox | | Operating System | Windows 11 | | Version | v2026.08.27e | | Device | Desktop | ## Preconditions User must be logged in and have access to the **SpikerSoft** interface. ## Steps to Reproduce 1. Log in to the SpikerSoft platform. 2. Navigate to **Learn > Geography Explorer**. 3. Locate the **Quick Actions** button at the bottom-right corner. 4. Click the button repeatedly at intervals of ~0.5 seconds. 5. Observe the submenu’s visibility behavior. ## Expected Result The submenu should consistently toggle between visible and hidden states with each click, regardless of click frequency. ## Actual Result - The submenu occasionally fails to appear. - In other cases, it remains visible and does not hide when clicked again. - The button’s visual state does not always reflect the submenu’s actual visibility. ## Evidence - The screenshot shows the **Geography Explorer** interface with the **Quick Actions** button visible in the bottom-right corner. - The tooltip “Show quick actions” confirms the button’s intended functionality. - Repeated clicks cause inconsistent submenu behavior. ## Impact - Reduces UI reliability and user confidence. - Interrupts workflow when users attempt to access quick actions rapidly. - Suggests potential asynchronous state conflicts in the button’s event handler. ## Frequency Intermittent (triggered by rapid clicks) ## Reproducibility 80–100% ## Severity Medium ## Notes The issue may be caused by: - Missing debounce or throttling logic in the click event handler. - Improper synchronization between submenu visibility state and button animation. It is recommended to implement a short debounce delay or state lock to ensure consistent toggle behavior.

Screenshot 2026-08-27 192131.png

632 KiB

spikerj referenced this issue from a commit

2026-08-30 21:18:32 +00:00

fix: the FAB dock hub always wins a click at its own position (fixes #901)

spikerj commented

2026-08-30 21:18:55 +00:00

I want to be straight with you: I have not confirmed this one, and I would rather say that than ship a guess and call it fixed.

What I checked: the button's open/closed state is a single atomic flip — there are no timers, no waiting on the animation, and nothing that remembers the state between page loads. I could not find a path in the code that leaves the button and the menu disagreeing. Your screenshot shows a self-consistent state too: the icon is rotated to its closed position and the tooltip reads "Show quick actions", which is exactly what a closed menu should look like.

What I did fix, because it is wrong regardless: while the menu is animating open, the action buttons are already clickable even though they are still invisible and still sitting on top of the main button. So a fast second click could land on a button you cannot see instead of on the hub. That is now impossible (spikerj/spikersoft-angular#902). It may or may not be your bug.

To pin it properly, could you tell me:

Does it still happen with slow, deliberate clicks (say one per second), or only when you click fast?
When it goes wrong, does the icon rotate (diamond ↔ grid)? That tells me whether the button knows its own state and the menu is failing to follow, or the click never registered at all.
Does the tooltip text match what you see — "Show quick actions" when the menu is hidden?
Roughly how many clicks before it misbehaves, and does reloading the page reset it?
Any chance the click is landing while the page is still loading?

Answers to 2 and 3 in particular would split this in half immediately.

I want to be straight with you: **I have not confirmed this one**, and I would rather say that than ship a guess and call it fixed. What I checked: the button's open/closed state is a single atomic flip — there are no timers, no waiting on the animation, and nothing that remembers the state between page loads. I could not find a path in the code that leaves the button and the menu disagreeing. Your screenshot shows a self-consistent state too: the icon is rotated to its closed position and the tooltip reads "Show quick actions", which is exactly what a closed menu should look like. What I did fix, because it is wrong regardless: while the menu is animating open, the action buttons are already clickable even though they are still invisible and still sitting on top of the main button. So a fast second click could land on a button you cannot see instead of on the hub. That is now impossible (spikerj/spikersoft-angular#902). It may or may not be your bug. **To pin it properly, could you tell me:** 1. Does it still happen with slow, deliberate clicks (say one per second), or only when you click fast? 2. When it goes wrong, does the **icon rotate** (diamond ↔ grid)? That tells me whether the button knows its own state and the menu is failing to follow, or the click never registered at all. 3. Does the tooltip text match what you see — "Show quick actions" when the menu is hidden? 4. Roughly how many clicks before it misbehaves, and does reloading the page reset it? 5. Any chance the click is landing while the page is still loading? Answers to 2 and 3 in particular would split this in half immediately.

spikerj commented

2026-09-13 21:29:54 +00:00

Follow-up, 2026-09-13: the fix mentioned above (spikerj/spikersoft-angular#902) is now live on production (build deployed 2026-09-13). While the menu opens, the hidden action buttons no longer catch a fast second click.

Your screenshot already answers one of my questions: the button is in its closed (diamond) state and the tooltip reads "Show quick actions", which matches a closed menu. So the button and the menu did agree at that moment.

Could you re-test on the current version, repeating your exact steps (Geography Explorer, a click about every 0.5s)?

If you can't make it misbehave any more, say so and I'll close this.
If you still can, tell me whether the icon rotates when it goes wrong. A short screen recording would be ideal: one video settles this faster than any description.

Follow-up, 2026-09-13: the fix mentioned above (spikerj/spikersoft-angular#902) is now **live on production** (build deployed 2026-09-13). While the menu opens, the hidden action buttons no longer catch a fast second click. Your screenshot already answers one of my questions: the button is in its closed (diamond) state and the tooltip reads "Show quick actions", which matches a closed menu. So the button and the menu did agree at that moment. Could you re-test on the current version, repeating your exact steps (Geography Explorer, a click about every 0.5s)? - If you **can't** make it misbehave any more, say so and I'll close this. - If you **still can**, tell me whether the icon rotates when it goes wrong. A short screen recording would be ideal: one video settles this faster than any description.

spikerj commented

2026-09-21 04:06:27 +00:00

Reproduced and split — the two symptoms have different causes, and only one is a bug. Fix for that one is in spikerj/spikersoft-angular#1160.

"It fails to appear entirely" — real bug, fixed

The button is only in the DOM while the chat is closed:

@if (!isOpen() && !inline()) { <button class="chat-toggle-btn" …> }

It therefore only disappears on the change-detection pass after your click. The handler was a toggle, so a second click arriving before that pass still hit the button that was technically still there and flipped the state straight back. Two fast clicks = open, then immediately closed = nothing on screen.

Your "approximately every half second" is what makes this reproducible — you were landing inside that window.

It now sets the state instead of flipping it, so extra clicks do nothing. Two regression tests cover it, including one that fires two real DOM clicks at the button.

"The submenu remains visible and does not hide" — not a bug

This one is worth explaining rather than "fixing", because it looks identical from the outside.

The chat window is anchored to the same corner as the button:

	position	size
button	`fixed; bottom: 20px; right: 20px`	60 × 60
chat window	`fixed; bottom: 20px; right: 20px`	400 × 600

So the moment it opens, the window completely covers the spot the button occupied. Your next click at that position lands on the chat window — its message-input area — not on a toggle. Nothing closes, because there is nothing there to close it.

That is the intended design: the floating button opens, and the chat header's own controls close and minimise. Turning the button into a persistent close control would mean floating a 60px circle over the chat's input area, or re-anchoring the window — a design change rather than a defect fix, so I have not made that call unilaterally. Happy to if you want it.

Not a race condition

Your report suggested "a race condition or improper state handling". Close: the state handling was wrong, but not concurrently — toggleChat was a single synchronous signal update. The problem was purely that the button outlives the state change by one frame.

Reproduced and split — the two symptoms have different causes, and only one is a bug. Fix for that one is in spikerj/spikersoft-angular#1160. ## "It fails to appear entirely" — real bug, fixed The button is only in the DOM while the chat is closed: ```html @if (!isOpen() && !inline()) { <button class="chat-toggle-btn" …> } ``` It therefore only disappears on the change-detection pass **after** your click. The handler was a toggle, so a second click arriving before that pass still hit the button that was technically still there and flipped the state straight back. Two fast clicks = open, then immediately closed = nothing on screen. Your "approximately every half second" is what makes this reproducible — you were landing inside that window. It now **sets** the state instead of flipping it, so extra clicks do nothing. Two regression tests cover it, including one that fires two real DOM clicks at the button. ## "The submenu remains visible and does not hide" — not a bug This one is worth explaining rather than "fixing", because it looks identical from the outside. The chat window is anchored to the *same corner* as the button: | | position | size | | --- | --- | --- | | button | `fixed; bottom: 20px; right: 20px` | 60 × 60 | | chat window | `fixed; bottom: 20px; right: 20px` | 400 × 600 | So the moment it opens, the window completely covers the spot the button occupied. Your next click at that position lands on the chat window — its message-input area — not on a toggle. Nothing closes, because there is nothing there to close it. That is the intended design: the floating button opens, and the chat header's own controls close and minimise. Turning the button into a persistent close control would mean floating a 60px circle over the chat's input area, or re-anchoring the window — a design change rather than a defect fix, so I have not made that call unilaterally. Happy to if you want it. ## Not a race condition Your report suggested "a race condition or improper state handling". Close: the state handling was wrong, but not concurrently — `toggleChat` was a single synchronous signal update. The problem was purely that the button outlives the state change by one frame.

spikerj commented

2026-09-27 05:06:58 +00:00

Closing in the 2026-09-27 tracker sweep — already implemented.

Closing: the 'fails to appear' half was a real double-click race. It's fixed by spikerj/spikersoft-angular#1160, where the floating button now opens rather than toggles, together with the earlier spikerj/spikersoft-angular#902. The 'stays visible' half is by design, because the chat window covers the button's corner. Please reopen with a recording if it still misbehaves on the current build.

Reopen if this still needs work.

Closing in the 2026-09-27 tracker sweep — already implemented. Closing: the 'fails to appear' half was a real double-click race. It's fixed by spikerj/spikersoft-angular#1160, where the floating button now opens rather than toggles, together with the earlier spikerj/spikersoft-angular#902. The 'stays visible' half is by design, because the chat window covers the button's corner. Please reopen with a recording if it still misbehaves on the current build. Reopen if this still needs work.

spikerj closed this issue

2026-09-27 05:06:58 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#1119