Bug 86624 - FILEOPEN: Manually placed legend is moved to top left corner
Summary: FILEOPEN: Manually placed legend is moved to top left corner
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: highest critical
Assignee: Markus Mohrhard
QA Contact:
URL:
Whiteboard: target:5.0.0 target:4.4.4
Keywords: bibisected, bisected, regression
: 88957 89081 89148 89163 89200 89371 90109 90581 90743 (view as bug list)
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2014-11-23 12:49 UTC by Laurent BP
Modified: 2015-12-17 08:39 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file with legend manually placed (14.12 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-11-23 12:49 UTC, Laurent BP
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent BP 2014-11-23 12:49:55 UTC
Created attachment 109895 [details]
Test file with legend manually placed

Description: Legend in chart appears always at top left corner if it has been manually placed

Steps to reproduce:
1. Create a chart
2. Click and drop legend to move it inside Chart
3. Save
4. Reload

Actual behavior:
Legend appears at top left corner

Expected behavior:
Legend should be at the place it has been placed

Reproduced with LibO 4.4.0.0.beta1

Not reproduced with LibO 4.3.4.1
Comment 1 Laurent BP 2014-11-23 13:12:17 UTC
Reproduced with
- Version: 4.4.0.0.alpha2+
Build ID: 6143fa5a89d9528fc11fed1e7fe96b9280d411a4
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-10_22:48:21
- Version: 4.4.0.0.alpha1+
Build ID: 9ecac3874d179b1d7aa6b45337001b1def06a9dd
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-22_06:31:01
- Version: 4.4.0.0.alpha0+
Build ID: 6a6e8628bdbe60931ce8e7fa9f4bb66170f7737b
TinderBox: Win-x86@42, Branch:master, Time: 2014-09-29_23:55:43

NOT reproduced with
- Version: 4.4.0.0.alpha0+
Build ID: 37b9ea92ba81d74764a2345a9c75c65bfd272d2b
TinderBox: Win-x86@42, Branch:master, Time: 2014-08-26_09:37:01

So regression introduced between 2014-08-26_09:37:01 and 2014-09-29_23:55:43
Comment 2 raal 2015-01-30 19:32:57 UTC
*** Bug 88957 has been marked as a duplicate of this bug. ***
Comment 3 Michael Weghorn 2015-01-30 19:52:23 UTC
This sounds like it was the same as bug 88848.

If so, which of the two should be marked as a duplicate?
Comment 4 raal 2015-01-30 20:36:40 UTC
bibisected by  Michael Weghorn 2015-01-30 19:48:26 UTC comment 2 from bug 88848

$ git bisect log
# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6
# good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81
git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048
# good: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd
git bisect good 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5
# bad: [a42da134cd542144fca7ba14cce86c2b409fc18a] source-hash-beadebc0f7eb5582fcb8dcb082d19afdf2751876
git bisect bad a42da134cd542144fca7ba14cce86c2b409fc18a
# bad: [5f697ca821720f76105e5539f0408e68a0647481] source-hash-f9695150942341a755a43996d4639eb623d7640b
git bisect bad 5f697ca821720f76105e5539f0408e68a0647481
# bad: [3b00b662438462a4b73b0531ffa6192fc7e72638] source-hash-0a5cd87e591d7f87bfab92716079af719259f143
git bisect bad 3b00b662438462a4b73b0531ffa6192fc7e72638
# good: [b4320c4383b3d61076ac1794797bd3162612889d] source-hash-da21f7da44dc577a08ea3bc210083dc8decf18bc
git bisect good b4320c4383b3d61076ac1794797bd3162612889d
# bad: [e1690f3a96306b42e829d63cb23a48e4b90603b5] source-hash-3d394257945f6b0a4bc4b5ea397a3942a59c5d06
git bisect bad e1690f3a96306b42e829d63cb23a48e4b90603b5
# bad: [5de848a6e0a36f6ba90e6c32fd126942fde3293c] source-hash-fd0a49bdd7cf7979d18feff003d1b5fbe53fdc14
git bisect bad 5de848a6e0a36f6ba90e6c32fd126942fde3293c
# bad: [153f4f2366399a0459129b5161cda0f3b9c0dfbc] source-hash-647f83afb618acbf75c8c6f0a4531bd1e76d8a7e
git bisect bad 153f4f2366399a0459129b5161cda0f3b9c0dfbc
# first bad commit: [153f4f2366399a0459129b5161cda0f3b9c0dfbc] source-hash-647f83afb618acbf75c8c6f0a4531bd1e76d8a7e
Comment 5 tagezi 2015-01-30 21:00:27 UTC
(In reply to Michael Weghorn from comment #3)
> This sounds like it was the same as bug 88848.
> 
> If so, which of the two should be marked as a duplicate?

Yes, it is a duplicate. An algorithm of the bug reproduction is the same.


But I am interested in another thing. Why did not we set "bloked"? Our rules of the version release suggest that a regression compared with the previous version is a reason to block the release.
https://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Definition

However, we stated that everything was normal, it was just a working situation.
Why do we produce the program with unusable functionality?
Comment 6 Malky 2015-01-31 08:48:46 UTC
I've got the same problem in 4.4.0.3 (40m0(Build:3) ) after upgrade.
Comment 7 Peter Harde 2015-01-31 10:50:27 UTC
I confirm this bug. The bug first occured after upgrading from Version 4.3.5~rc2-0ubuntu1~precise1 to
4.4.0-rc3-0ubuntu1-precise1.
I am using Ubuntu 12.04
Comment 8 raal 2015-02-04 11:49:12 UTC
*** Bug 89081 has been marked as a duplicate of this bug. ***
Comment 9 raal 2015-02-06 18:56:59 UTC
*** Bug 89148 has been marked as a duplicate of this bug. ***
Comment 10 raal 2015-02-07 07:03:07 UTC
*** Bug 89163 has been marked as a duplicate of this bug. ***
Comment 11 raal 2015-02-07 13:53:36 UTC
*** Bug 89200 has been marked as a duplicate of this bug. ***
Comment 12 raal 2015-02-14 11:07:20 UTC
*** Bug 89371 has been marked as a duplicate of this bug. ***
Comment 13 bernard 2015-02-14 12:26:43 UTC
Hello,

As i told in  Bug 89371, tried to get out of the stable branch by testing the 4.4.0.3., where i discovered this bug, that forbids me to use libreoffice : what is more important in profesional use than diagrams ? So i came back to stable branch.

Please note also that the legend moves also when i generate pdf, so i cannot even place all legends then makes pdf to keep the rigth view.
Comment 14 Peter Hartmann 2015-02-20 14:03:01 UTC
Hello,
The bug is still there on version 4.4.1.1
I'm using Windows XP
Comment 15 tim 2015-02-24 16:31:18 UTC
Still a problem in Version: 4.4.1.2 Build ID: 40m0(Build:2) (ubuntu 14.04).
Comment 16 Andrew 2015-02-24 21:16:36 UTC
I can confirm the problem remains with the windows 4.4.1.2 version as well. Build ID: 45e2de17......
Comment 17 Robinson Tryon (qubit) 2015-03-05 20:05:04 UTC
Setting priority to highest as this is a 4.4 MAB. This is part of an effort to
make the importance of MAB reflected in priority too.
Comment 18 Peter Hartmann 2015-03-13 03:43:43 UTC
The same problem with 4.4.2.1
Linux 32bit (mageia4)
Comment 19 136c8j+6nqir6fvfr2xw 2015-03-14 17:29:21 UTC
Really annoying. This also happens for charts in writer.
Comment 20 Matthew Francis 2015-03-15 04:15:15 UTC
This seems to have been introduced by the below commit

    commit b067ead2ee8f162374c81b35190b0201a306ae04
    Author:     Kohei Yoshida <kohei.yoshida@collabora.com>
    AuthorDate: Wed Sep 24 16:16:54 2014 -0400
    Commit:     Kohei Yoshida <kohei.yoshida@collabora.com>
    CommitDate: Wed Sep 24 16:19:27 2014 -0400
    
        Don't update chart view when the controllers are locked.
    
        Change-Id: I8468925e63db3a5cc5ef3e0f942d22478fd0863e
Comment 21 raal 2015-03-21 17:39:42 UTC
*** Bug 90109 has been marked as a duplicate of this bug. ***
Comment 22 tim 2015-03-25 22:22:00 UTC
For such a high priority issue things seems strangely quiet here.  It's not even assigned yet. With no projected fix in sight I am having to considering downgrading my version, which will be somewhat painful since other previously resolved problems will come back and bite me in thecposterior.

Is there any likelihood of getting some information about when or if this problem will be looked at?
Comment 23 tim 2015-03-31 09:37:05 UTC
Still present in Version: 4.4.2.2, Build ID: 40m0(Build:2), Locale: en_GB
Comment 24 krajcsi 2015-03-31 11:30:03 UTC
Legend is moved if you copy the chart. It means that you cannot even copy-and-paste a chart correctly.

However, the legend is not moved if you export the chart.

My version: 4.4.2.2

This makes the involved LO versions useless if legend should be moved.
Comment 25 krajcsi 2015-03-31 11:39:42 UTC
The file modified with 4.4 opened with Version: 4.3.6.2 looks good: the legend is in the position where it was moved to in 4.4, although 4.4 does not display it correctly.
Comment 26 Laurent BP 2015-04-12 15:18:01 UTC
(In reply to Matthew Francis from comment #20)
> This seems to have been introduced by the below commit
> 
>     commit b067ead2ee8f162374c81b35190b0201a306ae04
>     Author:     Kohei Yoshida <kohei.yoshida@collabora.com>
>     AuthorDate: Wed Sep 24 16:16:54 2014 -0400
>     Commit:     Kohei Yoshida <kohei.yoshida@collabora.com>
>     CommitDate: Wed Sep 24 16:19:27 2014 -0400
>     
>         Don't update chart view when the controllers are locked.
I can confirm that this commit introduced the bug, with the ability to skip update if controllers are locked. However in SchXMLLegendContext::StartElement
opengrok.libreoffice.org/xref/core/xmloff/source/chart/SchXMLLegendContext.cxx#197
  xLegendShape->setSize( aLegendSize );
there is a call to impl_updateView() (through  ChartView::getRectangleOfObject)
http://opengrok.libreoffice.org/xref/core/chart2/source/view/main/ChartView.cxx#1943 
and there it needs an update.

I proposed a dirty fix in ChartView::getRectangleOfObject if it is called for a legend:
https://gerrit.libreoffice.org/15268/ may be not so nice, but it fixes the bug on my master. May be Kohei would have a better way to fix it.
Comment 27 Matthew Francis 2015-04-13 02:26:24 UTC
*** Bug 90581 has been marked as a duplicate of this bug. ***
Comment 28 Yousuf Philips (jay) 2015-04-14 06:25:56 UTC
Should be noted that the start center thumbnail shows the legend in the correct location. attachment 114755 [details]
Comment 29 Laurent BP 2015-04-14 11:10:23 UTC
(In reply to Jay Philips from comment #28)
> Should be noted that the start center thumbnail shows the legend in the
> correct location. attachment 114755 [details]

What you see in start center, is just a preview image stored when the file was saved. It is not calculated by LibO. So, in this case, image just says that when the file was saved, legend was at the right place.
Comment 30 Laurent BP 2015-04-14 16:42:21 UTC
The solution I proposed is not acceptable.
Comment 31 Yousuf Philips (jay) 2015-04-14 16:54:47 UTC
(In reply to Laurent BP from comment #29)
> What you see in start center, is just a preview image stored when the file
> was saved. It is not calculated by LibO. So, in this case, image just says
> that when the file was saved, legend was at the right place.

No this is incorrect.

<kendy> jphilipz: ... there are 2 thumbnails: one in ODF, one for the startcenter.
<kendy> jphilipz: In the older LibreOffice versions, the one from the file were shown, now we use the one in the profile.
Comment 32 Peter Hartmann 2015-04-18 02:27:31 UTC
Still present in 4.4.3.1
Linux 32 bit
Comment 33 Yousuf Philips (jay) 2015-04-18 09:42:09 UTC
Returning it back to 4.4 master.
Comment 34 raal 2015-04-20 14:24:35 UTC
*** Bug 90743 has been marked as a duplicate of this bug. ***
Comment 35 Janek M 2015-04-21 17:38:25 UTC
I've done some debugging and found the following results:

1) creating a chart with arbitrary location of the legend; and saved it to .ods.
2) I've unzipped the .ods file
3) I've examined ~/Object 1/content.xml

there's a tag <chart: legend svg:x="XVALUE" svg:y="YVALUE" ...
it seems that XVALUE and YVALUE contain the correct legend's location, in cm.

Then I've reopened the .ods file and the legend moved to top-left corner of the chart.

4) I've resaved the incorrect location of the legend into a new .ods file
5) I've unzipped the new .ods file
6) examining ~/Object 1/content.xml

The XVALUE and YVALUE are not both set to zero (since the legend was in the top-left corner).

My conclusion is that since the XVALUE and YVALUE were properly saved, the problem is during opening of the .ods file.


Also. If I use one of the presents (top, bottom, left, right) for the legend position the content.xml file has chart:legend-position="MYPOSITION".

8) Then if I manually edit content.xml to change "MYPOSITION" to "MYPOSITION2"
9) rezip the files back to .ods file
10) opening the newely zipped .ods file in Calc properly reflects MYPOSITION2 for the legend.

This further concludes that during the opening Calc has trouble parsing the svg:x="XVALUE" and svg:y="YVALUE" values. But it has no trouble parsing chart:legend-position="POSITION" when top/bottom/left/right is used.
Comment 36 Commit Notification 2015-05-02 19:12:20 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=774257d6708ea059c108ac2831a583dafc385370

it works if we first set the size and then the position, tdf#86624

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 37 Commit Notification 2015-05-02 19:12:25 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf52d1951587bea895902c8b030a19942dd0ba69

add test for tdf#86624

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 38 Laurent BP 2015-05-02 19:55:31 UTC
Thanks moggi :)
I'll test it as soon as possible.
Comment 39 Laurent BP 2015-05-03 11:14:34 UTC
I can confirm that bug is fixed on master.

It now needs to be backported on 4.4. Surely too late for 4.4.3, but would be great for 4.4.4 ;)
Comment 40 Laurent BP 2015-05-03 21:37:44 UTC
Backport to 4.4 is on the way :)
https://gerrit.libreoffice.org/15600/
Comment 41 Commit Notification 2015-05-09 20:03:40 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a01d54ba65d3ef20eebb5f943cfe8a18daad22a8&h=libreoffice-4-4

it works if we first set the size and then the position, tdf#86624

It will be available in 4.4.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 42 Peter Hartmann 2015-05-12 19:44:01 UTC
It works for me on win XP.
LO 4.4.4 daily of 2015-05-11
Thanks.
Comment 43 tim 2015-06-17 08:49:01 UTC
Works for me - ubuntu Version: 4.4.4.2 Build ID: 40m0(Build:2) Locale: en_GB.UTF-8
Comment 44 Robinson Tryon (qubit) 2015-12-17 08:39:54 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]