Bug 112641 - freeze rows/columns functions incorrect or unexpected when frozen rows/columns don't fit in Window
Summary: freeze rows/columns functions incorrect or unexpected when frozen rows/column...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0
Keywords:
: 100666 109173 112659 115303 124653 125420 129429 132554 146061 146501 148538 (view as bug list)
Depends on:
Blocks: Cell-Freeze
  Show dependency treegraph
 
Reported: 2017-09-25 10:52 UTC by Winfried Donkers
Modified: 2022-11-26 15:33 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Calc document with folded rows in frozen rows (10.03 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-09-26 09:57 UTC, Winfried Donkers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Winfried Donkers 2017-09-25 10:52:44 UTC
Description:
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


Actual Results:  
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

Expected Results:
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


Reproducible: Always

User Profile Reset: No

Additional Info:
Tested in Windows (version 5.3.6.1) and Linux (version 5.2.3.3).


User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 m.a.riosv 2017-09-26 09:44:57 UTC
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
Comment 2 Winfried Donkers 2017-09-26 09:57:59 UTC
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.
Comment 3 Holger Klene 2018-04-03 23:22:59 UTC
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
Comment 4 Holger Klene 2018-04-03 23:25:11 UTC
*** Bug 115303 has been marked as a duplicate of this bug. ***
Comment 5 Telesto 2018-04-04 07:20:51 UTC
Adding UX Eval based on comment 3
Comment 6 Holger Klene 2018-04-04 18:55:34 UTC
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).
Comment 7 Heiko Tietze 2018-04-07 15:17:07 UTC
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).
Comment 8 Xisco Faulí 2019-04-16 10:41:47 UTC
*** Bug 124653 has been marked as a duplicate of this bug. ***
Comment 9 Xisco Faulí 2019-05-22 14:44:04 UTC
*** Bug 125420 has been marked as a duplicate of this bug. ***
Comment 10 Xisco Faulí 2019-12-26 11:46:53 UTC
*** Bug 129429 has been marked as a duplicate of this bug. ***
Comment 11 QA Administrators 2021-12-26 04:21:02 UTC Comment hidden (obsolete)
Comment 12 Winfried Donkers 2021-12-30 13:18:22 UTC
(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+.
Comment 13 Buovjaga 2022-01-25 18:27:18 UTC
*** Bug 146501 has been marked as a duplicate of this bug. ***
Comment 14 Aron Budea 2022-07-20 02:44:51 UTC
*** Bug 100666 has been marked as a duplicate of this bug. ***
Comment 15 Aron Budea 2022-07-20 02:46:46 UTC
*** Bug 109173 has been marked as a duplicate of this bug. ***
Comment 16 Aron Budea 2022-07-20 02:46:55 UTC
*** Bug 112659 has been marked as a duplicate of this bug. ***
Comment 17 Aron Budea 2022-07-20 02:47:03 UTC
*** Bug 132554 has been marked as a duplicate of this bug. ***
Comment 18 Aron Budea 2022-07-20 02:47:14 UTC
*** Bug 148538 has been marked as a duplicate of this bug. ***
Comment 19 Aron Budea 2022-07-20 02:47:38 UTC
*** Bug 146061 has been marked as a duplicate of this bug. ***
Comment 20 Justin L 2022-11-02 11:10:56 UTC
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.
Comment 21 Commit Notification 2022-11-02 16:20:51 UTC
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.
Comment 22 Heiko Tietze 2022-11-07 15:09:15 UTC
(In reply to Commit Notification from comment #21)
> Justin Luth committed a patch related to this issue.

Resolved fixed?
Comment 23 Justin L 2022-11-26 15:33:41 UTC
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.