Version 0.4.0 (Git Repo) – Report: New behavior of the "floppy disk" save icon

As previously reported here:
https://github.com/nextcloud/documentserver_community/issues/401

document saving behavior (tested with spreadsheets) is somewhat unexpected (though not entirely incorrect).

Since the "Autosave" function saves only every n-th change to the file rather than every single one, I tested additional options today (using files stored locally in Nextcloud and files on an SMB share with "save credentials in session" enabled).

Test 1:
ONLYOFFICE > Menu > Collaboration > Mode: co-editing
It was set to "Fast"; I am now setting it to "Formal".
Result:
The behavior I observed is EXACTLY what one would expect from "Fast" co-editing mode. After every change, an "Autosave" action appears in the GUI; i.e., the diskette icon briefly turns black (potentially clickable) after the change and then turns gray (no longer clickable). In "Formal" mode, too, the file is saved only after every nth change.

The previous behavior was different:
As soon as a change occurred (i.e., something worth saving was altered in the document), the diskette icon became clickable. After clicking it (which had to be done manually rather than automatically), it turned gray again until the next change.

So, there is an issue with the "Fast"/"Formal" co-editing mode switch—possibly related to the structurally altered saving strategy.

Test 2:
ONLYOFFICE > Menu > Collaboration > Mode: Co-editing
Reset to "Fast"
and
Nextcloud > Menu: Administration > ONLYOFFICE > "Keep intermediate versions during editing (force save)" = Checkbox now selected

In this mode, the behavior is significantly different:
The diskette icon is now ALWAYS black and clickable—even when the document has just been opened and no changes have been made.

When changes are made to the document, data is written to the file only every nth time (though the value of n may differ slightly).
However, in this mode, the diskette icon can be clicked at any time, and clicking it actually saves the currently displayed version to the file.

Note:
When closing a document (closing the tab), the currently displayed version is—in principle—saved to the file. IF it works, it seems to work across all variants (Fast/Formal/Force-save); however, WHETHER it works appears to depend on the browser:
Mullvad: No saving when closing the tab
Safari: Saves when closing the tab—but sometimes the file gets corrupted in the process and can no longer be opened "locally."

"Online," the file (which is corrupted on the storage medium) can still be opened (presumably retrieved from the document server's working cache?) and generates a valid file again upon saving—provided this is done from a different browser than the one that caused the save error.

In this mode ("Keep intermediate versions during editing (force save)"), saving to the file appears to be reliable (at least based on tests involving individual edits). The only confusing aspect is that the icon remains black, which gives the impression that there are unsaved changes.

This likely stems from the standard way the system has historically displayed the icon after save operations:

• After saving, the icon is supposed to turn gray to indicate that the save has taken place (whether it needs to be unclickable is a separate question).
• Unsaved changes are meant to be indicated by a black icon—which is also clickable.

With the previous "autosave" issue, the system believed the data had been written and—based on that assumption—switched the icon to gray, thereby making it unclickable.

The recent changes to saving behavior evidently affect—or are linked to—how the floppy disk icon is displayed.

General note regarding the save icon:

• A save function should ALWAYS be clickable, regardless of whether the system believes it has just performed a save.

• It is fine for the icon to appear gray after saving (or when no changes have been made) to reflect that state—but manual saving (clicking) must always be possible.

-Alternatively, the icon could be displayed in different colors depending on the selected save strategy and settings (quick, formal, force-save), rather than just switching between black and gray.

However, this would require devising a set of self-explanatory color codes first.

General note on closing the editor:
In my opinion, the rather unreliable results obtained when tracking actions like closing tabs, windows, or the browser could easily be avoided:

The solution most intuitive for the majority of users would be a "Close" icon within the app (the ONLYOFFICE editor).
The absence of such an icon confuses many users who want to exit "their program" properly—and quite a few wonder if "their document" might still be open somewhere in the background.

Such a "Close" icon would be easy to implement and would really only need to provide a few functions.

Upon clicking the "Close" icon:

1. Display a confirmation dialog:
   Ask whether to save changes.
   If "Yes" – trigger a save operation.
   If "No" – do not save; skip the usual autosaves that occur when closing tabs/windows, etc. (it should, after all, be possible to leave a document untouched if no edits were made).
   After "Yes" or "No" (and the corresponding actions), simply switch to the "Files" (or other defined) area (ideally to the location where the document was stored).
   If cancelled – simply close the confirmation dialog.

I imagine that neither adjusting the behavior of the save icon nor integrating a "Close" icon would be particularly difficult—though this is likely something for the ONLYOFFICE developers to handle?

Start with the related report in issue #401 and reproduce the spreadsheet behavior described here using Fast and Formal co-editing, force-save, local files, and SMB shares. Compare the save icon state and file contents after edits, manual saves, and closing tabs in Mullvad and Safari. Done would require an agreed, reproducible scope for the save indicator and closing behavior.