Bug 116892 - FILEOPEN: Rotated Objects Anchored to Cells set Move when Opened
Summary: FILEOPEN: Rotated Objects Anchored to Cells set Move when Opened
Status: RESOLVED DUPLICATE of bug 119191
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency tree / graph
 
Reported: 2018-04-08 23:56 UTC by Luke
Modified: 2019-12-12 11:33 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Square shape originally anchored to B2 (9.21 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-04-08 23:57 UTC, Luke 		Details
tail of terminal output, daily Linux dbgutil bibisect (2.29 KB, text/plain)
2018-04-16 22:48 UTC, Terrence Enger 		Details
Comparison LibreOffice 6.0 and Master (133.09 KB, image/png)
2018-04-17 14:59 UTC, Xisco Faulí 		Details
screenshot of 3.6.7.2 vs 4.3.7.2 (66.54 KB, image/png)
2018-04-20 05:05 UTC, Luke 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2018-04-08 23:56:42 UTC 
Steps to reproduce.
1. In Calc, in B2, insert a shape
2. Set Anchor "To Cell, Resize with Cell"
3. right click -> Position and Size -> rotate by some angle
3. Save 
4. Close and re-open 

Expected behavior
1. Shape stays in same position 

Actual behavior
1. Shape moves on each save
Comment 1 Luke 2018-04-08 23:57:41 UTC 
Created attachment 141216 [details]
Square shape originally anchored to B2
Comment 2 Samuel Mehrbrodt (allotropia) 2018-04-09 05:59:30 UTC 
This seems to happen when the shape is larger than the cell it's anchored to.
Comment 3 Samuel Mehrbrodt (allotropia) 2018-04-10 08:32:42 UTC 
Also seen in 5.4.x, so not a regression from my changes.
Comment 4 Luke 2018-04-10 16:57:09 UTC 
No repo in LibreOffice 3.3.4. A file saved with 5.3+ is correctly centered. Subsequent save, close, re-open cycles do not result in the shape moving.
Comment 5 Terrence Enger 2018-04-16 22:48:43 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2018-04-17 14:59:49 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2018-04-17 15:03:18 UTC Comment hidden (obsolete)
Comment 8 Luke 2018-04-20 05:05:40 UTC 
Created attachment 141497 [details]
screenshot of 3.6.7.2 vs 4.3.7.2

I agree with Samuel here. I can reproduce this in 5.4, 5.3, 4.3, but not in 3.3 or 3.6. So this regression occurred between 3.6 and 4.3

Use these steps to reproduce this bug:
1. Open attachment 141216 [details]
2. Compare location of rectangle with my screenshot. LO 3.6 is correct. 4.3 is wrong. 

I think Xisco & Terrence bisected a different bug.
Comment 9 Luke 2018-04-21 03:25:37 UTC 
I'm going to put in a bibisect for the regression that occurred here:

Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)
Good

Version: 4.1.0.1
Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155
BAD


attachment 141497 [details] shows the issue that I was reporting. 

The bug Xisco & Terrence identified is probably related to Bug 116931. Changing anchor type from "To Cell, Resize with Cell" to "To Cell" will workaround this bug.
Comment 10 Buovjaga 2018-07-07 15:13:27 UTC 
It seems I hit the bullseye with 41max: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2b1aa949539d2fcbb3d349be3c279996630d83fc
fdo#56276 - resize/reposition rotated shapes in a sensible way

Committer is retired.
Comment 11 QA Administrators 2019-10-07 03:03:05 UTC Comment hidden (obsolete)
Comment 12 Regina Henschel 2019-10-07 11:03:53 UTC 
The error still exists in Version: 6.4.0.0.alpha0+ (x64)
Build ID: b2d8093b19642038631dfb8f1ab6745a380a652c
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-23_22:42:37
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded
Comment 13 Luke 2019-10-07 16:29:35 UTC 
Raising priority as suggested for orphaned regressions in past -qa IRC discussion.
Comment 14 Buovjaga 2019-10-07 16:47:31 UTC 
Severity is its own animal, so setting back to normal
Comment 15 Regina Henschel 2019-12-08 00:25:37 UTC 
I think, it is the same reason as bug 119191. It looks good with my (not yet finished) local patch.
Comment 16 Xisco Faulí 2019-12-12 11:13:46 UTC 
(In reply to Regina Henschel from comment #15)
> I think, it is the same reason as bug 119191. It looks good with my (not yet
> finished) local patch.

Hi Regina,
Actually your patch < 
https://git.libreoffice.org/core/commit/f44140bebb9c493d97ba5aef26c9692c53a6b93f > breaks attach document. After RT, the drawing is just a line...
Comment 17 Xisco Faulí 2019-12-12 11:27:05 UTC 
(In reply to Xisco Faulí from comment #16)
> (In reply to Regina Henschel from comment #15)
> > I think, it is the same reason as bug 119191. It looks good with my (not yet
> > finished) local patch.
> 
> Hi Regina,
> Actually your patch < 
> https://git.libreoffice.org/core/commit/
> f44140bebb9c493d97ba5aef26c9692c53a6b93f > breaks attach document. After RT,
> the drawing is just a line...

so, taking a deeper look at this issue, indeed, it's fixed by f44140bebb9c493d97ba5aef26c9692c53a6b93f, thus, closing as a duplicate of bug 119191.
OTOH, it causes the mentioned problem after saving the document. I'll create a follow-up bug

*** This bug has been marked as a duplicate of bug 119191 ***
Comment 18 Xisco Faulí 2019-12-12 11:33:09 UTC 
(In reply to Xisco Faulí from comment #17)
> OTOH, it causes the mentioned problem after saving the document. I'll create
> a follow-up bug
> 
> *** This bug has been marked as a duplicate of bug 119191 ***

See bug 129339