I can repro 4. and 5. but not 13. and 15.
Version: 5.4.2.1 (x64)
Build ID: dfa67a98bede79c671438308dc9036d50465d2cb
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: es-ES (es_ES); Calc: group

Created attachment 136539 [details]
Calc document with folded rows in frozen rows

The attachment show the problem described in step 11 etc.

Open the document;
Adjust the Calc form to have not more than 30 rows;
select any row below the freeze marker line;
click on the group '+' to unfold rows.

Result : the freeze setting is lost.

I suppose this is a "feature" designed, to protect someone from opening their spreadsheet on a low resolution beamer and being unable to scroll as the whole screen is taken up by frozen cells. So dragging the window to a small rectangle, until the frozen line touches the scrollbar will disable the freeze-status for that axis.

This has multiple strange effects. You better not:
- unfold cells within the frozen range (as of this bug)
- drag toolbars around
- expand the properties sidebar
- paste text in a multiline-cell that automatically wraps
- toggle screen resolution to duplicate output to some ancient beamer
- resize the window, e.g. pressing <Windows>+<Left>

All those (and possibly more, I didn't think of) are triggers that reset freeze-status. To top it off, the document does not get dirty by this inadvertent change. But saving it due to other changes will persist the unfrozen state.

On the other hand, manually freezing the cells again after such an incident will make the document dirty and ask to save, if you try to close it.

I suggest making the freeze-state ternary:
a) disabled - nothing is frozen
b) enabled - cells are fixed
c) "temporary suspended" - the viewport is not big enough to show anything other than the frozen rows / columns, so freezing them is obsolete, until later, when the conditions change.

This status is to be tracked independently for both axis.

Please also have a look at: #99477

Adding UX Eval based on comment 3

Another sidenote on the suggested ternary state: I think, it doesn't affect the saved file. The new "temporarily suspended" depends on the viewport, that may be completely different the next computer, LO is opening it. So from a persistence perspective cells are binary frozen or not.

So the saved binary state expresses the users intention of how the table is supposed to work on an sufficiently big enough screen (this is to be save in the file). In contrast the ternary state is what Calc should make of it if squeezed into insufficient space (this is not to be saved directly, only derived from the saved state).

Looks like an ordinary bug: expanding a grouped section (e.g. with the tiny plus left of the sheet) makes the frozen area disappear - but only if this row is out of the scroll area. It does not happen with row 4, for instance. (Didn't test with columns.)

Freezing and grouping are two different use cases and should work independently. I don't think a third state to disable one in case of the other is helpful (beyond a workaround).

(In reply to QA Administrators from comment #11)
Behaviour as described in description and comment#2 can still be reproduced with version 7.1.4.2 (openSUSE Leap 15.3) as well as with version 7.4.0.0.alpha+.

This is going to be extremely tricky to resolve.

Losing the freeze when the window is too small is already seen in LO 3.5, and I'm sure it is inherited from OOo. (An easy way to test is to zoom in, and then zoom out again.)

The ability to freeze only the first row/col came in LO 5.2 with
commit a009ba2b8ed7ead021ecc3356a477a08e72d2191.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ef4f3b565aa312a57dd75a6334c460d9a7df2650

NFC related tdf#112641: fix off-by-one-space formatting

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Commit Notification from comment #21)
> Justin Luth committed a patch related to this issue.

Resolved fixed?

Interesting, the bug failed to capture

tdf#112641 sc: always allow freezing at cell A1

applied to master with commit e6bc90aa8a959e08abf4b5c10d793ff9a549efe4.

That allows the following to always work:  View - Freeze first column / Free first row.


For the more general situation, suggested patch https://gerrit.libreoffice.org/c/core/+/142129 needs a bit more work.