Bug Hunting Session
Bug 104643 - FILESAVE: Frozen row is not saved in XLS or XLSX (wayland)
Summary: FILESAVE: Frozen row is not saved in XLS or XLSX (wayland)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.3.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 114797 (view as bug list)
Depends on:
Blocks: Wayland Cell-Freeze
  Show dependency treegraph
 
Reported: 2016-12-13 14:22 UTC by pavelz
Modified: 2018-11-16 16:37 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pavelz 2016-12-13 14:22:06 UTC
Description:
Frozen row is not saved when saving file to XLS or XLSX, only frozen column is saved in these formats. This bug does not affect saving to ODS.


Steps to Reproduce:
1. Create a new file in Calc
2. Go e.g. to B2 cell
3. Click "Freeze Rows and Columns" button in the toolbar (or use View/Freeze Cells" menu
4. Save file as XLS or XLSX
5. Exit Calc
6. Open the saved file

Actual Results:  
The row is not frozen (only the column is).

Expected Results:
Both the row and column should be frozen.


Reproducible: Always

User Profile Reset: No

Additional Info:
It looks that if Calc is not exited and only the file is closed and reopened the status of frozen row is remembered. But it is forgotten when Calc exits.



User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Xisco Faulí 2016-12-13 15:12:10 UTC
I can't reproduce it in

Version: 5.4.0.0.alpha0+
Build ID: 634589b340316ba64b731b4d923c1056be415494
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

or

Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 2 pavelz 2016-12-13 15:52:13 UTC
Tried with a new profile, but the issue persists.

Version: 5.2.3.3
Build ID: 5.2.3.3-11.fc25
CPU Threads: 2; OS Version: Linux 4.8; UI Render: default; 
Locale: cs-CZ (cs_CZ.UTF-8); Calc: group
Comment 3 Buovjaga 2016-12-17 21:01:44 UTC
No repro. Tried also with GTK3 as I noticed Fedora being used by reporter.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 06ea887f8ba34a628d7641eab210501f7bd2493d
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 16th 2016
Comment 4 pavelz 2016-12-19 14:38:00 UTC
Investigated the issue further and it seems that it does not manifest when the file is opened from within LibreOffice application.

I mean the issue is apparent when opening the file e.g. from file manager by double-click on its icon, which is the most common way in my usage, but also manifests when the XLS file is used as a parameter of "libreoffice" command in terminal.

So it seems to me that it is not an issue of saving the frozen row status but rather an issue of opening the file.
Comment 5 Buovjaga 2016-12-19 15:03:14 UTC
(In reply to pavelz from comment #4)
> I mean the issue is apparent when opening the file e.g. from file manager by
> double-click on its icon, which is the most common way in my usage, but also
> manifests when the XLS file is used as a parameter of "libreoffice" command
> in terminal.

Well, I don't see the issue when opening like that.
Comment 6 pavelz 2016-12-19 16:49:36 UTC
It must be specific to my environment then. I tried to reproduce that in live session of Fedora 25, which should be closest to what I am running just now and the issue is not there.

It is really strange, I am running Fedora 25 (upgraded from 24), but there were already some updates to LO, so my version of LO is not the same as in the live session. I also tried to reinstall LO packages but it makes no difference.

I filed the bug against Red Hat bugzilla - https://bugzilla.redhat.com/show_bug.cgi?id=1406081
Comment 7 raal 2017-07-03 18:21:32 UTC
no repro. Version: 6.0.0.0.alpha0+
Build ID: 77f77c57d336ba041faf51e2168372d1e0962a19
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-06-29_23:40:47

I think we can close the bug?
Comment 9 Xisco Faulí 2017-07-04 09:44:26 UTC
Please test with a master build as mentioned in comment 8
Comment 10 pavelz 2017-07-04 18:04:50 UTC Comment hidden (obsolete)
Comment 11 pavelz 2017-07-04 18:27:27 UTC
(In reply to pavelz from comment #10)
> Cannot reproduce it more with the current version, so changing status to
> resolved.
> 
> Version: 5.2.7.2
> Build ID: 5.2.7.2-4.fc25
> CPU Threads: 2; OS Version: Linux 4.11; UI Render: default; VCL: gtk3; 
> Locale: cs-CZ (cs_CZ.UTF-8); Calc: group

Sorry, I was too quick, the issue is still present in 5.2.7.2-4.fc25, but it only manifests under wayland session.

Leaving status as resolved, because it works in fresh master even under wayland:

Version: 6.0.0.0.alpha0+
Build ID: 6e7300d1046a195068fa97a0d91a95f19cc5c056
CPU threads: 2; OS: Linux 4.11; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-03_23:43:13
Locale: cs-CZ (cs_CZ.UTF-8); Calc: group
Comment 12 Buovjaga 2017-07-04 18:40:45 UTC
Hmm, I think we should leave open, because you used gtk2 backend with the master build. I'm not sure, if we have a master build with gtk3 included.
Comment 13 pavelz 2017-07-04 19:01:53 UTC
(In reply to Buovjaga from comment #12)
> Hmm, I think we should leave open, because you used gtk2 backend with the
> master build. I'm not sure, if we have a master build with gtk3 included.

Probably you are right, when SAL_USE_VCLPLUGIN=gtk is set the issue is not even in 5.2.7.2-4.fc25 under wayland (gtk2 is used).

SAL_USE_VCLPLUGIN=gtk3 has no effect on master build, gtk2 is still used. SAL_USE_VCLPLUGIN=gen works for both.

So from my lay view it looks like a problem with gtk3 under wayland, not sure what the proper status should be set.
Comment 14 m.a.riosv 2018-01-02 15:20:48 UTC
*** Bug 114797 has been marked as a duplicate of this bug. ***
Comment 15 subha 2018-03-30 10:59:09 UTC
//Steps to Reproduce:
//1. Create a new file in Calc
//2. Go e.g. to B2 cell
//3. Click "Freeze Rows and Columns" button in the toolbar (or use View/Freeze //Cells" menu
//4. Save file as XLS or XLSX
//5. Exit Calc
//6. Open the saved file

//Actual Results:  
//The row is not frozen (only the column is).

//Expected Results:
//Both the row and column should be frozen.

Cannot able to reproduce this issue..
This issue is working fine in Windows 7 (32 bit),LibreOffice 6.0.2 ....
Try to close the ticket......
Comment 16 Buovjaga 2018-03-30 11:26:33 UTC
Bug 114797 was about Windows. XLSX was not mentioned. Terry: was your problem seen with ODS?

This bug is about XLS or XLSX on Linux with GTK3 and Wayland.
Comment 17 Xisco Faulí 2018-10-24 11:17:55 UTC
Hello pavelz,
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 18 pavelz 2018-11-16 15:48:29 UTC
Cannot reproduce any more.

Version: 6.0.6.2
Build ID: 6.0.6.2-3.fc28
CPU threads: 2; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: cs-CZ (cs_CZ.UTF-8); Calc: group