Download it now!
Bug 103924 - border style duplicated / changed by new borders when round-tripping
Summary: border style duplicated / changed by new borders when round-tripping
Status: RESOLVED DUPLICATE of bug 104097
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Cell-Border
  Show dependency treegraph
 
Reported: 2016-11-14 11:34 UTC by Justin L
Modified: 2017-10-20 09:07 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
borderStyle.ods. Add another border and reload to replicate the issue (10.15 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-11-14 11:37 UTC, Justin L
Details
borderStyle.pdf: B2:F3 should be all black, with top-middle borders only. (10.42 KB, application/pdf)
2016-11-14 11:43 UTC, Justin L
Details
reservedNames.diff: debug output and code pointing to key concern areas. (18.32 KB, patch)
2016-11-16 06:22 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2016-11-14 11:34:52 UTC
Description:
Existing borders are substituted for different ones because the imported style names are not properly stored in the reserved names.  Thus duplicates are created, and existing styles are replaced with the new ones which likely have different border attributes.

Steps to Reproduce:
1. In Calc, create a border pattern in B2:F3
2. Save (as ods is fine), close, and re-open
3. create a different border pattern (change color to make it obvious) in B5:C6
4. Save, close, and reopen.  Notice that the border in B2:F3 has been affected.

Actual Results:  
The border pattern is different since some cells now have colored borders in different places.

Expected Results:
The untouched border in B2:F3 should be unaffected by borders added elsewhere in the document.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 Justin L 2016-11-14 11:37:33 UTC
Created attachment 128745 [details]
borderStyle.ods. Add another border and reload to replicate the issue
Comment 2 Justin L 2016-11-14 11:43:57 UTC
Created attachment 128747 [details]
borderStyle.pdf: B2:F3 should be all black, with top-middle borders only.

Regression in 5.3 development branch.  Used linux daily 5.3 dbgutil bibisect to isolate to the changes made on Sept 24, the most likely problem commit being
author	Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-09-26 19:37:12
commit	89804c14ee99721d252e30468342384fbc8926b2
  implement prototype for more stable calc cell style names
Comment 3 Xisco Faulí 2016-11-14 12:18:31 UTC
Confirmed in 

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

and confirmed that this regression was caused by 89804c14ee99721d252e30468342384fbc8926b2

author	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-09-24 18:41:52 (GMT)
committer	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-09-26 19:37:12 (GMT)
commit	89804c14ee99721d252e30468342384fbc8926b2 (patch)
tree	a543fb27fe9333b4a204aabba4ef984a2cb09f57
parent	f626fd5f897796451685c06ce5f397a90aeaa8e6 (diff)

implement prototype for more stable calc cell style names
This should ensure that as long as the style does not change the cell
style name is the same after an import export cycle.

Each ScPatternAttr stores a unique ID and we store the ID to name
mapping during import. During export if we find a ScPatternAttr that has
a key that is also stored in the map we write back the style name from
the map.
To avoid name collisions we block the style names from the import for
the export.

The missing piece to make this completely awesome is now to make sure
that styles are sorted by name during export. That way we can reduce the
diff between import and export even more.

Adding Cc: to Markus Mohrhard
Comment 4 Justin L 2016-11-16 06:22:45 UTC
Created attachment 128780 [details]
reservedNames.diff: debug output and code pointing to key concern areas.

The problem is that the reserved names end their life before they are used as seen by this line from the AutoStyleFamily destructor:

warn:DEBUG:11022:1:xmloff/source/style/impastpl.cxx:59: ?????? ~XMLAutoStyleFamily[table-cell] DTOR  reserved.size[8] ???????

Markus: best if you take over from here.
Comment 5 Justin L 2017-01-21 11:59:46 UTC
This is a fairly nasty bug to be allowed to hit shipping code.
Comment 6 Justin L 2017-10-20 09:07:49 UTC
fixed: target:5.4.0 target:5.3.0.1

*** This bug has been marked as a duplicate of bug 104097 ***