Bug 124653 - Frozen pane disapear on window resize
Summary: Frozen pane disapear on window resize
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
: 115303 120117 125420 129429 131637 142787 146061 146501 156075 (view as bug list)
Depends on:
Blocks: Cell-Freeze
  Show dependency treegraph
Reported: 2019-04-10 12:27 UTC by françois dambrine
Modified: 2024-01-18 18:48 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description françois dambrine 2019-04-10 12:27:13 UTC
When we have many columns in "frozen" state, resizing the window removes the state.

Steps to Reproduce:
1. select column A to E
2. in View tab click "freeze rows and columns"
3. save your document so that it can be now reopened with frozen panes
4. resize your window with a width little enough not to display D column
5. restore to full screen

Actual Results:
no column is frozen
no change is detected, so "save" icon does not notify us of a "not saved version"

Expected Results:
column A, B, C and D are frozen, like before

Reproducible: Always

User Profile Reset: No

Additional Info:
We can note that if we have two sheets in workbook only the active sheet is impacted.
Comment 1 mulla.tasanim 2019-04-13 05:39:52 UTC
Thank you for reporting the bug.

I can confirm that the bug is present in

Version: (x64)
Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

Version: (x64)
Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 2 Xisco Faulí 2019-04-16 10:41:47 UTC
it seems like a duplicate of bug 112641

*** This bug has been marked as a duplicate of bug 112641 ***
Comment 3 Justin L 2023-01-20 15:11:22 UTC
While this is quite similar to bug 112641, that is actually describing a different state related to folding/unfolding. So lets keep these two separate. Most duplicates are dealing with this specific concern of resizing/zooming.

I personally am not convinced that this is actually a bug. It is a rather critical safety precaution.
Comment 4 Justin L 2023-01-20 15:12:38 UTC
*** Bug 129429 has been marked as a duplicate of this bug. ***
Comment 5 Justin L 2023-01-20 15:13:40 UTC
*** Bug 146501 has been marked as a duplicate of this bug. ***
Comment 6 Justin L 2023-01-20 15:15:07 UTC
*** Bug 146061 has been marked as a duplicate of this bug. ***
Comment 7 Justin L 2023-01-20 15:15:55 UTC
*** Bug 115303 has been marked as a duplicate of this bug. ***
Comment 8 Justin L 2023-01-20 15:17:00 UTC
*** Bug 125420 has been marked as a duplicate of this bug. ***
Comment 9 Justin L 2023-01-20 15:29:02 UTC
*** Bug 120117 has been marked as a duplicate of this bug. ***
Comment 10 Justin L 2023-01-20 15:29:32 UTC
*** Bug 131637 has been marked as a duplicate of this bug. ***
Comment 11 Justin L 2023-01-20 15:30:03 UTC
*** Bug 142787 has been marked as a duplicate of this bug. ***
Comment 12 Justin L 2023-01-20 15:53:35 UTC
I'm sure this is a WONTFIX.

The computer has no way of knowing the reason for the screen being too small to show freeze point. So for safety reasons it needs to remove the freeze.
Plus, the computer doesn't really have the ability to know why the split was removed. Do you really want the computer to store and check every time the window is zoomed/resized/sidebarred/ minimized etc whether it cancelled a freeze and that this was the last freeze action taken? That is a lot of processing power that would be unnecessary 99.999% of the time.

Displaying a user "warning" about the automatic removal of the freeze seems excessive to me. I would not use a program that bombards me with dialogs about trivial things. Pretty much every reporter figured out the reason for the lost freeze on their own, which shows it is relatively transparent.

The easy solution is to reset the freeze at the desired cell.
Comment 13 Lorenz 2023-01-23 07:46:45 UTC
may I ask what savtey reasons you are refering too?
Comment 14 ady 2023-06-27 10:27:15 UTC
*** Bug 156075 has been marked as a duplicate of this bug. ***
Comment 15 Adrian E 2024-01-18 18:48:14 UTC
I can confirm this is still a bug in the following LO version

Version: / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.4
Calc: threaded

This bug also appears to also act on a per-axis basis, so for example, if I have both frozen rows and frozen columns, and I shrink the height such that not all the frozen rows are visible, only the frozen rows will be reset, I will still be able to horizontally scroll and the frozen columns will stay as they were supposed to be.

In my own experience, I have been annoyed by this issue for at least a couple years, especially since I use an LTS version of a popular Ubuntu-based desktop environment that seems to has a bug where plugging in external monitors causes all windows to resize themselves to be really small, thus causing this bug to be unintentionally reproduced quite frequently on my machine, requiring me to take several clicks and seconds to to disable (because its still enabled) frozen rows and columns and then re-enable them to reset the document's behavior. Despite only being a few clicks and a few seconds, the frequency with which this happens adds up quickly. As the wise XKCD authors suggest in comic 1205, it seems as though each person in a similar situation to mine can afford to spend a low-single-digits number of hours fixing this issue before it becomes more effort than it would save. 

I would also be interested in understanding the reasoning behind why fixing this issue not possible for safety reasons.

One potential solution I believe might work: If the behavior for handling frozen rows and columns was configurable in the settings, a note explaining the safety issue could potentially be added either in settings or as a popup upon changing the setting. This would resolve the concerns with being intrusive to users with repetitive notifications as they would only see a notification if they changed that setting from its safety-first default. This would also not require substantially more computation every time a window is resized as it would act to prevent the "disable frozen rows/cols" behavior in the first place, rather than trying to selectively re-introduce it back in.