# [Bug] Text Selection Enabled Across UI Causing Interaction Conflicts at SpikerSoft Stacker #1137

New Issue

2026-09-14T01:09:11Z

enjin2310 commented

2026-09-14 01:09:11 +00:00

Summary

In SpikerSoft Stacker, text selection is enabled throughout the interface, including panels, buttons, and labels. This behavior allows users to highlight text that should be static, leading to interaction conflicts — especially in the right-hand panel, where text selection interferes with clickable elements on lower-resolution monitors.

Issue Description

Text selection is active in nearly all sections of the application, such as Frames, Stacks, and Touch up panels. When users attempt to interact with buttons or sliders, accidental text highlighting can occur. On smaller screens, this causes the selection overlay to block or delay interaction with UI components like “Use as base” or “Export” buttons.

Environment

Property	Value
Application	SpikerSoft Stacker
Module	UI / Interaction
Environment	Production
Operating System	Windows 11
Version	v2026.09.13
Device	Desktop

Preconditions

User must be running the app on a monitor with reduced resolution or smaller display area.

Steps to Reproduce

Open SpikerSoft Stacker.
Navigate to any section (e.g., Touch up, Frames, or Stacks).
Attempt to select text or click on buttons in the right-hand panel.
Observe that text can be highlighted and that interaction with clickable elements becomes inconsistent.

Expected Result

Text selection should be disabled in non-editable UI components to ensure uninterrupted interaction.

Actual Result

Text selection is enabled across the interface.
Selecting text interferes with clickable elements, especially in the right panel.
The issue is more noticeable on lower-resolution monitors.

Evidence

The screenshot shows the Touch up workspace where text selection is active in multiple panels.
Interaction with “Use as base” and “Export” buttons can be interrupted when text is highlighted.

Impact

Reduces usability and responsiveness of the interface.
Causes confusion and accidental selection during workflow.
Affects accessibility and precision in user interactions.

Frequency

Always

Reproducibility

100%

Severity

Medium

Notes

The issue can be resolved by applying a CSS rule such as:

user-select: none;
to non-editable UI components, ensuring that text selection is restricted only to input fields or editable areas.

## Summary In **SpikerSoft Stacker**, text selection is enabled throughout the interface, including panels, buttons, and labels. This behavior allows users to highlight text that should be static, leading to interaction conflicts — especially in the right-hand panel, where text selection interferes with clickable elements on lower-resolution monitors. ## Issue Description Text selection is active in nearly all sections of the application, such as **Frames**, **Stacks**, and **Touch up** panels. When users attempt to interact with buttons or sliders, accidental text highlighting can occur. On smaller screens, this causes the selection overlay to block or delay interaction with UI components like “Use as base” or “Export” buttons. ## Environment | Property | Value | |-----------|--------| | Application | SpikerSoft Stacker | | Module | UI / Interaction | | Environment | Production | | Operating System | Windows 11 | | Version | v2026.09.13 | | Device | Desktop | ## Preconditions User must be running the app on a monitor with reduced resolution or smaller display area. ## Steps to Reproduce 1. Open **SpikerSoft Stacker**. 2. Navigate to any section (e.g., **Touch up**, **Frames**, or **Stacks**). 3. Attempt to select text or click on buttons in the right-hand panel. 4. Observe that text can be highlighted and that interaction with clickable elements becomes inconsistent. ## Expected Result Text selection should be disabled in non-editable UI components to ensure uninterrupted interaction. ## Actual Result - Text selection is enabled across the interface. - Selecting text interferes with clickable elements, especially in the right panel. - The issue is more noticeable on lower-resolution monitors. ## Evidence - The screenshot shows the **Touch up** workspace where text selection is active in multiple panels. - Interaction with “Use as base” and “Export” buttons can be interrupted when text is highlighted. ## Impact - Reduces usability and responsiveness of the interface. - Causes confusion and accidental selection during workflow. - Affects accessibility and precision in user interactions. ## Frequency Always ## Reproducibility 100% ## Severity Medium ## Notes The issue can be resolved by applying a CSS rule such as: ```css user-select: none; to non-editable UI components, ensuring that text selection is restricted only to input fields or editable areas.

SpikerSoft Stacker 9_13_2026 9_01_36 PM.png

1.4 MiB

spikerj referenced this issue from a commit

2026-09-20 22:55:25 +00:00

fix(app): stop labels from selecting text across the UI

spikerj closed this issue

2026-09-20 23:06:47 +00:00

spikerj commented

2026-09-21 04:12:17 +00:00

Fixed and released — please re-test on v2026.09.21a or later.

Your report was valid when you filed it against v2026.09.13. The fix is 8ab6d59 "fix(app): stop labels from selecting text across the UI" (2026-09-20), and git tag --contains puts the first release carrying it at v2026.09.21a.

The fix is a global style change in theme.rs:

style.interaction.selectable_labels = false;

The comment above it describes the mechanism you hit almost exactly:

egui makes every label selectable by default, so a label senses click and drag: pressing a frame row or a format card starts a text selection and the container never sees the click, and an ordinary drag across a panel leaves stray highlight behind.

That "the container never sees the click" is the part matching your note about "Use as base" and "Export" being blocked or delayed — the label was swallowing the press before the button got it.

Two details worth knowing for the re-test:

TextEdit is unaffected, so anywhere you actually type is still fully selectable.
Strings genuinely worth copying into a support thread opt back in through a copyable() helper — error text like decode failed: DSC_0042.ORF, for instance. So selection is not gone everywhere, just off for chrome.

Both behaviours are covered by tests (running_app_keeps_labels_unselectable, plus one asserting an opted-in label still reports a selectable sense), so it should not silently regress.

Leaving this open for you to confirm on your own hardware, since the original symptom was resolution-dependent and I cannot reproduce that side of it here.

Fixed and released — please re-test on **v2026.09.21a** or later. Your report was valid when you filed it against v2026.09.13. The fix is `8ab6d59` *"fix(app): stop labels from selecting text across the UI"* (2026-09-20), and `git tag --contains` puts the first release carrying it at **v2026.09.21a**. The fix is a global style change in `theme.rs`: ```rust style.interaction.selectable_labels = false; ``` The comment above it describes the mechanism you hit almost exactly: > egui makes every label selectable by default, so a label senses click and drag: pressing a frame row or a format card starts a text selection and the container never sees the click, and an ordinary drag across a panel leaves stray highlight behind. That "the container never sees the click" is the part matching your note about **"Use as base"** and **"Export"** being blocked or delayed — the label was swallowing the press before the button got it. Two details worth knowing for the re-test: - **`TextEdit` is unaffected**, so anywhere you actually type is still fully selectable. - Strings genuinely worth copying into a support thread opt back in through a `copyable()` helper — error text like `decode failed: DSC_0042.ORF`, for instance. So selection is not gone everywhere, just off for chrome. Both behaviours are covered by tests (`running_app_keeps_labels_unselectable`, plus one asserting an opted-in label still reports a selectable sense), so it should not silently regress. Leaving this open for you to confirm on your own hardware, since the original symptom was resolution-dependent and I cannot reproduce that side of it here.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#1137