Bug 153702 - Alert dialog about closing score with unsaved changes highlights "Don't save" by default!
Summary: Alert dialog about closing score with unsaved changes highlights "Don't save"...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2023-02-17 21:38 UTC by R. Green
Modified: 2023-02-28 03:21 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Unsaved changes dialog (18.92 KB, image/png)
2023-02-17 21:38 UTC, R. Green
Details
close warning popup on Windows (9.53 KB, image/png)
2023-02-27 14:36 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description R. Green 2023-02-17 21:38:46 UTC
Created attachment 185451 [details]
Unsaved changes dialog

Version: 7.5.0.3 (X86_64) / LibreOffice Community
Build ID: c21113d003cd3efa8c53188764377a8272d9d6de
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

If you try to close a score with unsaved changes you get an alert box (see attachment). However the "Don't save" option is highlighted by default!

EXPECTED RESULT: "Save" should be highlighted instead.
Comment 1 Rafael Lima 2023-02-17 23:40:40 UTC
This does not happen with KDE dialogs.

In gtk3, although the "Don't Save" button appears first and is red, pressing Enter immediately after this dialog is shown will select the "Save" button.

Can you confirm this behavior?
Comment 2 R. Green 2023-02-27 10:11:57 UTC
(In reply to Rafael Lima from comment #1)
> In gtk3, although the "Don't Save" button appears first and is red, pressing
> Enter immediately after this dialog is shown will select the "Save" button.
> 
> Can you confirm this behavior?

Version: 7.5.0.3 (X86_64) / LibreOffice Community
Build ID: c21113d003cd3efa8c53188764377a8272d9d6de
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Calc: threaded

Confirmed. Pressing enter immediately saves any changes even though "Don't save" is the default highlighted option.
Comment 3 Rafael Lima 2023-02-27 11:46:36 UTC
This only happens in gtk3 dialogs.

I believe the reason why "Don't Save" is read is to alert the user that this is an operation that might cause data loss. It does not mean that the button is selected.

Still, I would consider it more natural to have the "Save" button first (and selected by default) and "Don't Save" second or last (in red color). 

Maybe we should have some input from the UX team on this matter.
Comment 4 Rafael Lima 2023-02-27 11:47:33 UTC
Typo in Comment #3 above:

I believe the reason why "Don't Save" is *red* is to alert the user that this is an operation that might cause data loss. It does not mean that the button is selected.
Comment 5 Adolfo Jayme Barrientos 2023-02-27 14:17:43 UTC
(In reply to R. Green from comment #2)
> Confirmed. Pressing enter immediately saves any changes even though "Don't
> save" is the default highlighted option.

Thanks for checking that this line works: https://cgit.freedesktop.org/libreoffice/core/tree/sfx2/uiconfig/ui/querysavedialog.ui#n61

The Arc theme shown in your screenshot should display default buttons with a dashed line. If it doesn’t, it may be a GTK bug (which I don’t expect GNOME to fix, since they’ve always shown contempt towards user customization).
Comment 6 V Stuart Foote 2023-02-27 14:36:06 UTC
Created attachment 185616 [details]
close warning popup on Windows

Are we sure it is => NOB against gtk3?

On the Windows builds also the button order/status is:

Save, Don't Save, Cancel

with the Save button clearly UI focused and active.

gtk3 - out of order and not reflecting actual button with focus seems more severe for our UI and something we should correct.
Comment 7 Caolán McNamara 2023-02-27 15:02:46 UTC
I think all is in order on our side.

"Save" has the default keyboard focus. That is normally shown with a dashed border (not seen in the original screenshot, but that's up the gtk anyway). FWIW I know gtk doesn't show keyboard focus unless the keyboard has been used, so it's possible to get a non-dashed case by e.g. launching libreoffice writer, right click to paste something and click x to close and the keyboard focus isn't shown, but in any case the default focus is in save.

The red is an indicator of a "destructive-action" which not saving is.

The button order in these warning dialogs are rearranged to match the button order of the Desktop Environment so Don't Save, Cancel, Save is the correct order for GNOME

For comparison purposes gedit has a very similar warning dialog with buttons in the same order, same focus default and with "destructive-action" on their "Close without Saving" equivalent
Comment 8 Rafael Lima 2023-02-27 17:48:42 UTC
(In reply to Caolán McNamara from comment #7)
> The button order in these warning dialogs are rearranged to match the button
> order of the Desktop Environment so Don't Save, Cancel, Save is the correct
> order for GNOME

I understand that this is a Gnome standard, but I still find it confusing every time I use apps in Gnome and the "Don't save" (or "Close without saving" in Gedit, Glade, etc) button appears first.

From what I understand, we have the ability to change this in LO if we choose to do so. So it might be a discussion about what is better UX-wise.

There are 2 main points to be made here:
1) Having the order changed to "Save", "Don't save" and "Cancel" in Gtk3 will make the experience equal to all OS/DEs, which is a good thing
2) However, I don't know how much such change would hurt the experience of Gnome users, who might already be accustomed to this sequence
Comment 9 Adolfo Jayme Barrientos 2023-02-27 19:38:58 UTC
That ship sailed a long time ago: we try to follow the macOS/GNOME order of negative-positive buttons on those DEs, and the Windows/KDE order in the respective environments.
Comment 10 Rafael Lima 2023-02-28 03:21:48 UTC
(In reply to Adolfo Jayme Barrientos from comment #9)
> That ship sailed a long time ago: we try to follow the macOS/GNOME order of
> negative-positive buttons on those DEs, and the Windows/KDE order in the
> respective environments.

Fair enough... This might have been an interesting discussion back in the day.

I believe it would be more appropriate to close this as WONTFIX.