Skip to content

keybindings: allow screenshot keys while a menu is open - #13952

Closed
rumours86 wants to merge 1 commit into
linuxmint:masterfrom
rumours86:allow-screenshots-while-modal
Closed

keybindings: allow screenshot keys while a menu is open#13952
rumours86 wants to merge 1 commit into
linuxmint:masterfrom
rumours86:allow-screenshots-while-modal

Conversation

@rumours86

Copy link
Copy Markdown

Pressing Shift+Print (area screenshot) with any menu or applet popup open does nothing: the area/window/clipboard screenshot keys are registered with ActionMode.NORMAL, so the modal filter swallows them. Meanwhile the full-screen SCREENSHOT key is already ALL and works in the same situation, as do the volume keys — which makes the dead Shift+Print feel like a bug to the user (that's exactly how it was reported to me).

Capturing the screen while a popup is open is a legitimate and common request, and the pickers in js/ui/screenshot.js handle starting on top of an existing modal (verified live: the picker opens, Escape cancels cleanly, selection completes cleanly).

This registers all six screenshot media keys with ActionMode.ALL.

🤖 Generated with Claude Code

Area/window/clipboard screenshot keys were registered with
ActionMode.NORMAL, so pressing e.g. <Shift>Print with any menu or applet
popup open did nothing - while the full-screen SCREENSHOT key (ALL) and
the volume keys worked fine in the same situation.  Capturing the screen
with a popup open is a legitimate and common request, and the pickers in
js/ui/screenshot.js handle running on top of an existing modal.

Register all screenshot media keys with ActionMode.ALL.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@mtwebster

Copy link
Copy Markdown
Member

Is this tested on muffin/cinnamon 6.7.*?

@rumours86

Copy link
Copy Markdown
Author

Live testing was on Cinnamon 6.6.9 (Mint 22.3), where the same behavior change was applied via the equivalent 6.6 code path (the Main.modalCount == 0 check in on_media_key_pressed): with a menu open, Shift+Print launches the area picker over the menu, Escape cancels cleanly, and a selection completes cleanly (the latter with #13948 applied — without it the picker's double-_ungrab bug can trigger regardless of how it was launched).

On 6.7/master I verified the path statically rather than live (I don't have a 6.7 environment running): the mode field from the MEDIA_KEYS table lands in entry.allowedModes, and both delivery paths — _filterKeybinding (WM) and the modal _stageEventHandler — share _shouldFilterKeybinding, which does the bitwise allowedModes & actionMode check. MK.SCREENSHOT is already ActionMode.ALL in that table and works while a menu is open, so this PR only brings the remaining five screenshot keys onto the same, already-exercised mechanism; no new code path is introduced.

Happy to adjust if you'd prefer this gated differently on 6.7.

🤖 Addressed by Claude Code

@mtwebster

Copy link
Copy Markdown
Member

I don't want speculative PRs - if you haven't tested this against git master, where it will be applied, then please don't open a pull request - this isn't a fix we'd backport to older versions.

What about your other, numerous PRs?

@mtwebster mtwebster closed this Aug 24, 2026
@rumours86

Copy link
Copy Markdown
Author

Fair enough — building current git master (muffin + cinnamon) right now to test against it properly; I'll report back here with results on master, and I'll do the same verification pass on the other PRs (#13948, #13949, #13950, #13951) before asking for any further review. For context on those: the patches were authored against master source, but live behavioral testing so far was on 6.6.9 — I'll close or update any of them that don't reproduce/hold on master.

🤖 Addressed by Claude Code

@rumours86

Copy link
Copy Markdown
Author

Done — I've now built current git master (muffin + cinnamon 6.7.5) and tested against it, nested with a scale-2 dummy monitor.

This PR, verified on master: with the patch, the AREA_SCREENSHOT entry registers with allowedModes = ActionMode.ALL; with a menu open (actionMode == POPUP) Main._shouldFilterKeybinding() returns false (allow) for it, while a NORMAL-mode key like LOGOUT still returns true (blocked) — so the change is precisely scoped. On unpatched master the same entry is blocked, reproducing the dead Shift+Print.

Status of the other PRs, all re-verified against master the same way:

Details posted on each PR. Apologies for the earlier speculative submission — everything still open is now tested where it applies.

🤖 Addressed by Claude Code

@rumours86

Copy link
Copy Markdown
Author

@mtwebster

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.

2 participants