Bug Hunting Session
Bug 85493 - VIEWING: In diagrams, tooltips shown over curve points show information about the wrong point when "Range for Name" cell values are not sorted in ascending order
Summary: VIEWING: In diagrams, tooltips shown over curve points show information about...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Windows (All)
: medium minor
Assignee: Not Assigned
Depends on:
Blocks: Chart
  Show dependency treegraph
Reported: 2014-10-26 21:17 UTC by Olivier DESCOUT
Modified: 2019-08-18 22:52 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

A calc sheet reproducing the issue (57.94 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-10-26 21:17 UTC, Olivier DESCOUT

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier DESCOUT 2014-10-26 21:17:32 UTC
Created attachment 108476 [details]
A calc sheet reproducing the issue

Problem description: 
When you make Calc generate a diagram of type "Line" from 2 data sets (one for the X axis, the other for the Y axis), Calc sorts the dataset values, based on X-axis values (ascending order), before displaying them in the diagram. For example, if the X-axis values are dates, these dates are sorted so that the diagram shows value in chronological order.
This is a nice feature, incidentally.

However, when you double-click on the diagram and let the mouse on one of the curve points, a tip shows up, but this tip gives wrong information if the X-axis values in the source range needed sorting before being displayed the diagram (actually, information given is not erratic, it just relates to the wrong cell in the source cell range).

How to reproduce the issue:
- Open the attached Calc document. It contains 4 sheets with the very same data, sorted in a different way each; every sheet also contains a diagram of type "Line" showing up these data graphically. Note that all 4 diagrams are strictly identical, since data are identical (though they are sorted with different criteria every time).
- Select any of the "... -- KO" sheet.
- Double-click on the diagram.
- Let the mouse over any point of the curve, et look at the tip info.

Every sheet in the attached Calc document also gives 3 examples of points, with their expected and actual tip texts.

Expected result:
The tip over any point in the diagram should take into account the fact that values were sorted when generating the diagram. Which means that the 1st point on the left in the diagram may not be the value of the 1st cell in the source cell range; the 11th point from the left in the diagram may not be the value of the 11th cell in the source cell range; and the last point on the right in the diagram may not be the value of the last cell in the source cell range.

Note: As a reference, I also added a sheet in the attached spreadsheet, named "Ascending Date -- OK", which shows that point tips are OK when the data are already sorted in ascending order in the source cell range.
Comment 1 Jean-Baptiste Faure 2014-11-11 15:52:34 UTC
The type "Line" does not use first column as abscissa, it uses it as labels. You can check that if you open the dialog Data Range. You will see that for your chart you do not have a data range for X values, only for Y values. In fact the X values are given by the line numbers.

If you want a chart with 2 data ranges, one for the X values and one for the Y values, you must use the type XY.

Best regards. JBF
Comment 2 Olivier DESCOUT 2014-11-11 21:43:27 UTC
@ Jean-Baptiste Faure

I agree with your note. However, if you look at the attached spreadsheet, you will see that tip information over the points in the curve does not match these points.

That's the point of this issue: no matter the type of diagram, the tip over a given point should give information on this particular point, and not on a different point located somewhere else in the curve.
Comment 3 Jean-Baptiste Faure 2014-11-11 21:47:19 UTC
I disagree, you give to the labels a meaning that is not intended by Chart. The first label is only the first label, whatever is written on the label.

Best regards. JBF
Comment 4 Olivier DESCOUT 2014-11-11 22:07:30 UTC
Sorry, but what is the purpose of displaying a pop-up tip when the mouse goes over a particular point of the curve if the shown tip gives information, not on that point, but on a point, which is completely different and located somewhere else? If I may say so, I'd say it makes the tip... simply pointless.
Comment 5 seb 2015-10-01 16:12:21 UTC
I can reproduce this in LO 5.0.1 (on Arch Linux).

The issue appears even when using an XY (scatter) chart type, as JBF suggested using instead.

It seems as if on rendering the chart, the X-Y values are laid out on the chart in some unspecified order, while the line will simply connect the points from leftmost to rightmost, discarding the order in the data series. When the mouse hovers on a point, the label it references is then relative to the first point in the line, instead of being the actual index in the data series of the point.

I would also expect the tooltip to refer to the correct point, as per the original reporter said.
Comment 6 Olivier DESCOUT 2016-02-11 21:32:12 UTC
I can reproduce this in LO (on Windows 6.1).
Comment 7 Olivier DESCOUT 2016-09-10 07:14:15 UTC
I can also reproduce this in LO (on Windows 6.1).
Comment 8 Olivier DESCOUT 2017-02-12 17:34:20 UTC
I can also reproduce this in LO (on Windows 6.1).
Comment 9 Olivier DESCOUT 2017-09-01 18:23:47 UTC
I can also reproduce this in LO (on Windows 6.19).
Comment 10 Olivier DESCOUT 2018-02-04 23:18:49 UTC
I can still reproduce this in LO (on Windows 10.0).
Comment 11 QA Administrators 2019-02-05 03:46:10 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

Comment 12 Olivier DESCOUT 2019-02-09 09:56:54 UTC
I can still reproduce this in LO and various LO 6.1.x (_x64) versions (on Windows 10.0).
Comment 13 Olivier DESCOUT 2019-02-09 10:03:25 UTC
Amendment to my previous comment: below are some additional information on the LO 6.2.0 version, against which I tested the bug again:
Version: (x64)
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
Threads CPU : 4; OS : Windows 10.0; UI Render : default; VCL: win; 
Locale : fr-FR (fr_FR); Langue IHM : fr-FR
Calc: threaded
Comment 14 Olivier DESCOUT 2019-08-18 22:52:03 UTC
I can still reproduce this with LO 6.3.

Please find below detailed LO version information:
Version: (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
Threads CPU : 4; OS : Windows 10.0; UI Render : par défaut; VCL: win; 
Locale : fr-FR (fr_FR); Langue IHM : fr-FR
Calc: threaded