Description: When zooming in to a sheet with Frozen Cells, the Freeze is (appropriately) disabled if the you zoom in too far to make the zoom workable. All good so far. If you (inevitably) zoom back out again, the Freeze Cells point is not reapplied. I suggest that the Freeze setting is merely disabled (rather than cancelled and forgotten) if display area is less than zoom area. A freeze point outside the currently zoomed area probably means that the former zoom setting will be returned to. Whadya think? Probably happened before ver 6.0.7 but I can't recall. I have Ubuntu 18.04LTS but I guess it is all OSes. Jx Steps to Reproduce: 1. Split screen (say half way down/across visible sheet) then freeze cells 2. Zoom in very close 3. Zoom out again Actual Results: Freeze point disappears Expected Results: Freeze point wanted back where I deliberately set it. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group OpenGL not enabled? Terminal shows: $ glxinfo | grep OpenGL Command 'glxinfo' not found, but can be installed with: sudo apt install mesa-utils
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
(In reply to Xisco Faulí from comment #1) > it seems you're using an old version of LibreOffice. Thanks for the reply. I am using the official, current ubuntu-bionic-upgrade version from Canonical, which usually lags behind LO-fresh. As I understand it, 6.0.7 is an official and current release of LO. From the LO Downloads page: > LibreOffice 6.0.7 > If you deploy LibreOffice in an enterprise or corporate environment > or are a conservative user, please choose this version. I am a borderline (small 'c') conservative user who welcomes (relative) stability so don't upgrade unless I am desperate for a feature. Are you saying that: - there no support for this seemingly current, official, stable, enterprise version? - this bug is fixed in 6.1.4 or merely unconfirmed in 6.0.7? Thanks!
(In reply to Jax from comment #2) > (In reply to Xisco Faulí from comment #1) > > it seems you're using an old version of LibreOffice. Errm... oops! When writing the previous comment, it seems like I was looking at an old, copycat website: https://newdesign.libreoffice.org/download/libreoffice-fresh/ So, according to https://www.libreoffice.org/download/download/ the current versions are 6.4.0 (Fresh) and 6.3.4 (Solid, or whatever it's called). Canonical are now lagging heavily, at least for 18.04LTS, although the snap version is 6.4.0. How stable is this likely to be and can anyone confirm this bug in LO 6.3.4 or later?
[Automated Action] NeedInfo-To-Unconfirmed
You can safely and easily test with an appimage: https://libreoffice.soluzioniopen.com/
(In reply to Buovjaga from comment #5) > You can safely and easily test with an appimage: > https://libreoffice.soluzioniopen.com/ Setting to NEEDINFO
Dear Jax, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
(In reply to QA Administrators from comment #7) > Dear Jax, > > This bug has been in NEEDINFO status with no change for at least > 6 months... Sorry, been offline a lot due to lockdowns. Due to a dead laptop, I am now running Xubuntu and LO 6.4.6.2. I downloaded an AppImage (from LibreOffice website directly) and can CONFIRM issue in the latest STILL version Steps taken: 1 Split spreadsheet in middle of screen 2 View > Freeze Rows and Columns 3 Zoom in hard so that the split in sheet is forced off the edge of the screen due to lack of space 4 Zoom out again 5 In my version, the split is not reapplied (as would be desireable) AppImage version: Version: 6.4.7.2 Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
Note: Horizontal and Vertical splits are independently lost or kept, depending upon whether they disappear due to lack of screen space during zoom.
Reproduced. Also with 3.3.0 on Win 10 Arch Linux 64-bit Version: 7.1.0.0.alpha1+ Build ID: c9b320c32aceab7e22d381b688e7b44030e01c2d CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 8 November 2020 Version: 7.1.0.0.alpha1+ (x64) Build ID: b61bf7c7cfcf97a5ade6d130873af146670bc2ee CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
Dear Jax, 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! Warm Regards, QA Team MassPing-UntouchedBug
I am not sure why OP says "appropriately disabled if the freeze delimit line is off-screen. I would argue that zoom level should never affect the freeze-state. Reproduced on: Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (C.UTF-8); UI: en-US Ubuntu package version: 4:25.2.5~rc2-0ubuntu0.24.04.1~lo1 Calc: threaded
I tried to fix this and there's a lot of complexity involved in tracking the frozen state so that it can kept when the file is saved and be restored correctly if the window is resized or zoomed out. It's necessary to be displaying the top row and/or left column when the frozen state is resumed, which can happen when scrolling or while dragging to select cells. https://gerrit.libreoffice.org/c/core/+/181728 https://gerrit.libreoffice.org/c/core/+/181729 https://gerrit.libreoffice.org/c/core/+/181730 It would be significantly simpler to just keep the freeze setting even if it means it won't be possible to scroll at all until the window is large enough for the contents, but I've not checked if that causes other problems.
(In reply to Simon Arlott from comment #14) > I tried to fix this and there's a lot of complexity involved in tracking the > frozen state so that it can kept when the file is saved and be restored > correctly if the window is resized or zoomed out. It's necessary to be > displaying the top row and/or left column when the frozen state is resumed, > which can happen when scrolling or while dragging to select cells. > > https://gerrit.libreoffice.org/c/core/+/181728 > https://gerrit.libreoffice.org/c/core/+/181729 > https://gerrit.libreoffice.org/c/core/+/181730 > > It would be significantly simpler to just keep the freeze setting even if it > means it won't be possible to scroll at all until the window is large enough > for the contents, but I've not checked if that causes other problems. License statement for reference, if someone wants to pick up the work: https://lists.freedesktop.org/archives/libreoffice/2025-February/093018.html