[0.7.1] Plain Text Editor - `Do you want to save?` Confirmation Dialog Doesn't Respect Tabbed Entries

[jthodge]

Description

In Plain Text Editor, when handling a modified document and using tabbed entries to select either Cancel or Delete, the Save As dialog opens regardless of the selected option.

Steps to Reproduce

1. Open a document in Plain Text Editor
2. Modify the document
3. Close Plain Text Editor via Title Bar "Close" button or ^|⌘+w
4. When presented with Do you want to save? confirmation dialog, <Tab> to Cancel or Delete
5. Press <Enter>

Expected Behavior

If Cancel:
Confirmation dialog closes. Plain Text Editor remains open and focus returns to the modified document.

If Delete:
Confirmation dialog closes. Plain Text Editor closes and deletes (i.e. does not save) modifications to the previously open document.

Actual Behavior

If Cancel:
Confirmation dialog closes. Save As dialog opens:

CleanShot.2025-01-30.at.13.46.18.mp4

If Delete:
Confirmation dialog closes. Save As dialog opens:

CleanShot.2025-01-30.at.13.51.28.mp4

Logs

N/A

Environment

• Platform and OS Version: macOS Sonoma 14.3
• Playbit Version: 0.7.1

[nickav]

For context, I think the confusion comes in because of the following:

In MacOS 13.5 (with Keyboard Navigation enabled), Space and Enter do the same thing to the tab-focused item.
In Playbit (currently), Space selects the focused item while Enter always triggers "Save" in this case.

EDIT: my mistake, it seems like MacOS actually has the same behavior as Playbit does currently

[jthodge]

@nickav Thank you for the clarifying explanation — appreciate the context 👍

[rsms]

@jthodge We are having a conversation in our team about this. I curious to hear what you think of the following idea: changing our behavior to make RETURN act on a keyboard-focused button, but otherwise act on the primary button.

I.e. the rule here is that while keyboard focus is on a button (any type of button; push button, pop-up button, checkbox, radio button, etc) the primary button no longer receives RETURN, but instead the focused button does.

Here's a more involved example with an input field "in the middle" of the UI-control sequence (notice that in frame 3 how the primary "Save" button becomes blue since then RETURN acts on it again.)

[jthodge]

@rsms

...make RETURN act on a keyboard-focused button, but otherwise act on the primary button.
I.e. the rule here is that while keyboard focus is on a button (any type of button; push button, pop-up button, checkbox, radio button, etc) the primary button no longer receives RETURN, but instead the focused button does.

+1: I support this interaction rule and would advocate for it being the updated behavior — that's exactly the behavior I expected¹.

And the rule also improves on that expected behavior! Specifically, the differentiation between focused and primary buttons, and which one <RETURN> will act on (e.g. as noted in frame 3 in the second diagram), is especially informative.

P.S. Clear, excellent explanation and workflow diagrams — love them both!

Footnotes

1. Thanks for outlining the "...but otherwise act on the primary button" case — that was my implicit expectation, but I didn't explicitly include it in the initial Issue. ↩

[edward-playbit]

Thank you for the issue report!
A fix for this has been made and will be released in a future update to Playbit.
(Internal ID: cd4a362f)