Description: 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.
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.2.1.2 (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: 6.3.0.0.alpha0+ (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
it seems like a duplicate of bug 112641 *** This bug has been marked as a duplicate of bug 112641 ***
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.
*** Bug 129429 has been marked as a duplicate of this bug. ***
*** Bug 146501 has been marked as a duplicate of this bug. ***
*** Bug 146061 has been marked as a duplicate of this bug. ***
*** Bug 115303 has been marked as a duplicate of this bug. ***
*** Bug 125420 has been marked as a duplicate of this bug. ***
*** Bug 120117 has been marked as a duplicate of this bug. ***
*** Bug 131637 has been marked as a duplicate of this bug. ***
*** Bug 142787 has been marked as a duplicate of this bug. ***
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.
may I ask what savtey reasons you are refering too?
*** Bug 156075 has been marked as a duplicate of this bug. ***
I can confirm this is still a bug in the following LO version Version: 7.3.7.2 / 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.