Bug 130319 - Zooming right in causes Freeze Cells point to be forgotten after inevitable zoom out again
Summary: Zooming right in causes Freeze Cells point to be forgotten after inevitable z...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Zoom-Issues Cell-Freeze
  Show dependency treegraph
 
Reported: 2020-01-31 12:39 UTC by Jax
Modified: 2020-11-09 06:10 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jax 2020-01-31 12:39:40 UTC
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
Comment 1 Xisco Faulí 2020-02-18 16:25:35 UTC
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.
Comment 2 Jax 2020-02-18 17:27:32 UTC
(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!
Comment 3 Jax 2020-02-18 18:01:12 UTC
(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?
Comment 4 QA Administrators 2020-02-19 03:31:28 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2020-05-10 15:50:48 UTC
You can safely and easily test with an appimage: https://libreoffice.soluzioniopen.com/
Comment 6 Xisco Faulí 2020-05-11 10:45:31 UTC
(In reply to Buovjaga from comment #5)
> You can safely and easily test with an appimage:
> https://libreoffice.soluzioniopen.com/

Setting to NEEDINFO
Comment 7 QA Administrators 2020-11-08 04:19:00 UTC Comment hidden (obsolete)
Comment 8 Jax 2020-11-08 14:11:22 UTC
(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
Comment 9 Jax 2020-11-08 14:14:45 UTC
Note:  Horizontal and Vertical splits are independently lost or kept, depending upon whether they disappear due to lack of screen space during zoom.
Comment 10 Buovjaga 2020-11-09 06:10:58 UTC
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