Freezing rows/columns that cannot all be shown causes rows/columns to become accessible unless 'unfrozen' and expanding folded groups within frozen rows/columns (so that not all frozen rows/columns can be shown in the window) causes the freeze setting to disappear. This setting does not reappear when folding the group again.
Either this is buggy behaviour or a decent user message is missing.
Steps to Reproduce:
1. create new Calc document
2. scroll down till at least row 1 is not longer visible
3. select any cell
4. choose 'View-Freeze cells-Freeze rows and columns'
5. unchoose 'View-Freeze cells-Freeze rows and columns'
10. create a new calc document
11. group rows 5-40 and fold these
12. go to row 45 (rows 1-4 and 41-45 are visible)
13. choose 'View-Freeze cells-Freeze rows and columns'
14. unfold the group
15. fold the group
4. the visible rows above the 'freeze marker line' are visible; rows above that cannot be shown
5. all rows can be accessed again
13. the -freeze-maker line' disappears and the freeze rows/columns setting is lost
15. the freeze rows/columns setting is not restored
4. an error message that the freeze cannot be applied as the numbers of rows to be frozen cannot all be shown in the window or a message that the invisible rows above and/or left of the window border can be reached again after unfreezing
13. an error message that the freeze cannot be applied as the numbers of rows to be frozen cannot all be shown in the window or a message that the invisible rows above and/or left of the window border can be reached again after folding the unfolded group
15. restoration of the freeze setting
User Profile Reset: No
Tested in Windows (version 220.127.116.11) and Linux (version 18.104.22.168).
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
I can repro 4. and 5. but not 13. and 15.
Version: 22.214.171.124 (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
*** Bug 115303 has been marked as a duplicate of this bug. ***
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).
*** Bug 124653 has been marked as a duplicate of this bug. ***
*** Bug 125420 has been marked as a duplicate of this bug. ***
*** Bug 129429 has been marked as a duplicate of this bug. ***
Dear Winfried Donkers (retired),
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
(In reply to QA Administrators from comment #11)
Behaviour as described in description and comment#2 can still be reproduced with version 126.96.36.199 (openSUSE Leap 15.3) as well as with version 188.8.131.52.alpha+.
*** Bug 146501 has been marked as a duplicate of this bug. ***
*** Bug 100666 has been marked as a duplicate of this bug. ***
*** Bug 109173 has been marked as a duplicate of this bug. ***
*** Bug 112659 has been marked as a duplicate of this bug. ***
*** Bug 132554 has been marked as a duplicate of this bug. ***
*** Bug 148538 has been marked as a duplicate of this bug. ***
*** Bug 146061 has been marked as a duplicate of this bug. ***
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
Justin Luth committed a patch related to this issue.
It has been pushed to "master":
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:
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.
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.