Bug 138505 - FILEOPEN XLSX: Experimental Feature: Cells with revised built-in styles reverted back to default style formats
Summary: FILEOPEN XLSX: Experimental Feature: Cells with revised built-in styles rever...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.0.beta1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2020-11-26 09:29 UTC by Kevin Suo
Modified: 2021-07-09 04:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
test xlsx document (5.82 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2020-11-26 09:29 UTC, Kevin Suo
Details
compare.pdf (56.80 KB, application/pdf)
2020-11-26 09:33 UTC, Kevin Suo
Details
autogen.input used for compiling (393 bytes, text/plain)
2020-11-27 10:52 UTC, Kevin Suo
Details
The example file in Calc (68.83 KB, image/png)
2020-12-09 08:54 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2020-11-26 09:29:21 UTC
Created attachment 167583 [details]
test xlsx document

The attached xlsx file has edited styles applied to each cell (i.e., I applied to the cells some pre-defined cell styles in Calc, then I changed some attributes to these styles). When open this xlsx file with Calc, the styles are reverted back to Calc's built-in default formats, rather than using the edited style formats.

Steps to Reproduce:
1. Open the attached xlsx file in Calc.

Expected Result:
There should be no cell background color, no font color, no cell borders.

Current Result:
All the cells are reverted to Calc's bult-in cell styles.

Version: 7.1.0.0.beta1+
Build ID: f3e7e5a6aa4d3eafb584f5d22c1a31bb0a3dd496
CPU threads: 4; OS: Linux 5.9; UI render: default; VCL: gtk3
Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN
Calc: threaded
Comment 1 Kevin Suo 2020-11-26 09:33:23 UTC
Created attachment 167584 [details]
compare.pdf
Comment 2 Kevin Suo 2020-11-26 10:02:50 UTC Comment hidden (obsolete)
Comment 3 Xisco Faulí 2020-11-26 10:08:53 UTC
Not reproduced in

Version: 7.2.0.0.alpha0+
Build ID: f981f756e1509ac0a39cd618316cfe3befd5923a
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

nor in

Version: 7.1.0.0.beta1+
Build ID: f3e7e5a6aa4d3eafb584f5d22c1a31bb0a3dd496
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 4 Kevin Suo 2020-11-27 01:43:03 UTC
I now realized and confirm that this bug appear only if I enable experimental feature.
Comment 5 QA Administrators 2020-11-27 04:41:59 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2020-11-27 09:17:46 UTC
@Ming, do you also reproduce this issue ?
Comment 7 Ming Hua 2020-11-27 10:17:06 UTC
(In reply to Xisco Faulí from comment #6)
> @Ming, do you also reproduce this issue ?
No, can not reproduce this one.

Got "expected result" when opening sample XLSX file with both 6.4.7 and master:

Version: 6.4.7.2 (x64)
Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded

Version: 7.1.0.0.alpha1+ (x64)
Build ID: 693553210828538680408832157faad9654758c8
CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: en-US
Calc: threaded
Comment 8 Kevin Suo 2020-11-27 10:27:12 UTC
This one should be different issue compared with bug 138506. 

For me, I can only reproduce on all the builds compiled on a Fedora 32 machine, but I can not reproduce with those compiled with a Fedora 30 machine. 
So I suspect it is dependent on building environment or autogen.input settings.
Comment 9 Kevin Suo 2020-11-27 10:52:00 UTC
Created attachment 167615 [details]
autogen.input used for compiling
Comment 10 QA Administrators 2020-11-28 04:29:58 UTC Comment hidden (obsolete)
Comment 11 NISZ LibreOffice Team 2020-12-09 08:54:16 UTC
Created attachment 167996 [details]
The example file in Calc

No repro with enabled experimental features in current nightly:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 796c7f612603490dda9277ced0f6ab3cce3bc116
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL
Comment 12 QA Administrators 2021-06-08 03:29:31 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2021-07-09 04:02:39 UTC
Dear Kevin Suo,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp