Skip to content

Fixed Copy menu item being disabled in the terminal context menu when text was selected while mouse reporting was enabled - #151

Merged
oleg68 merged 1 commit into
nbplugins:mainfrom
oleg68:bugfix/copy-disabled-work-profile
Jun 9, 2026
Merged

oleg68 merged 1 commit into
nbplugins:mainfrom
oleg68:bugfix/copy-disabled-work-profile

Conversation

@oleg68

@oleg68 oleg68 commented Jun 9, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Fixes the terminal context menu's "Copy" item being permanently disabled after a mouse-drag selection when Claude Code's TUI has enabled mouse reporting (DECSET 1000/1006). The bug appeared profile-dependent because Claude toggles mouse reporting dynamically based on TUI state, but was actually independent of the profile.
  • Root cause: JediTerm forwards plain left-button drags to the application instead of creating a local TerminalSelection when mouse reporting is active; with no selection, TerminalPanel$12.isEnabled(null) returns false and Copy is greyed out.
  • Fix: NetBeansSettingsProvider.forceActionOnMouseReporting() now returns true, so isLocalMouseAction() always returns true and drag always creates a selection. Click forwarding to the TUI is not relied upon (option menus are handled separately by ScreenContentDetector / ChoiceMenuPanel).

Test plan

  • mvn package — all 878 tests pass
  • In a session where Claude Code is actively producing output (mouse reporting on): drag-select text in the terminal → right-click → Copy is enabled and copies the selection
  • In a session at idle prompt (mouse reporting off): same flow still works
  • Ctrl+C still copies selection (regression guard)
  • Zoom submenu still present in the popup (regression guard for ZoomableJediTermWidget)

🤖 Generated with Claude Code

… text was selected by mouse drag while Claude Code's TUI had mouse reporting enabled

JediTerm's right-click Copy is enabled iff TerminalPanel.mySelection != null
at popup-build time. When the running TUI has enabled mouse reporting
(DECSET 1000/1006), JediTerm forwards plain left-button drag events to the
application instead of creating a local TerminalSelection — so the user
sees no selection in JediTerm's model and Copy is permanently disabled.
Claude Code toggles mouse reporting dynamically based on its TUI state,
which is why the bug appeared profile-dependent.

NetBeansSettingsProvider now overrides forceActionOnMouseReporting() to
return true, which makes JediTerm's isLocalMouseAction() always true and
lets mouse drag create a selection regardless of the application's
mouse-tracking state. Click forwarding to the TUI is not relied upon by
the plugin (option menus are handled separately by ScreenContentDetector
and ChoiceMenuPanel), so suppressing it has no user-visible cost.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@oleg68
oleg68 merged commit 686dac6 into nbplugins:main Jun 9, 2026
3 checks passed
@oleg68
oleg68 deleted the bugfix/copy-disabled-work-profile branch June 9, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant