Bug Hunting Session
Bug 66223 - Incorrect column names
Summary: Incorrect column names
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-26 19:49 UTC by Laurent Lyaudet
Modified: 2015-04-03 18:28 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
screen capture of first bug (95.77 KB, image/png)
2013-06-26 19:49 UTC, Laurent Lyaudet
Details
screen capture of second bug (21.91 KB, image/png)
2013-06-26 19:50 UTC, Laurent Lyaudet
Details
xlsx to reproduce the bug (20.32 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2013-06-26 19:51 UTC, Laurent Lyaudet
Details
second xlsx to reproduce the bug (18.94 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2013-06-29 18:41 UTC, Laurent Lyaudet
Details
third xlsx to reproduce the bug (20.37 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2013-06-29 18:42 UTC, Laurent Lyaudet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Lyaudet 2013-06-26 19:49:49 UTC
Created attachment 81499 [details]
screen capture of first bug

Hi,

I've found a bug when opening an xlsx file.
Column names are not ABCD...
but BCDEFG JKL...
(first screen capture)
I've checked here :
http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=53850
than it's not supposed to be possible to rename columns.

Moreover, I emptied the xlsx file (Ctrl A, del) in LibreOffice to remove unneeded informations and found another bug (second screen capture).
The second bug must be related since the display of columns names is quite messed up.

Both bugs appear on Windows 7 and Ubuntu so I assume it's not hardware or OS specific.
On Ubuntu, LibreOffice is 
LibreOffice 3.5.7.2 
Version ID : 350m1(Build:2)

On Windows 7, I don't remember which version I have but it must be one of the latest.
Since it seems to be a problem with xlsx support, I doubt it matters.
I'll note the version tomorrow and add it to the bug report if needed.


I'll join the two screen captures and the emptied xlsx file.
Let me know if I can help further.

Steps to reproduce : Open the xlsx file. Click on column names for "funny" effects.

Best regards,
   Laurent Lyaudet
Comment 1 Laurent Lyaudet 2013-06-26 19:50:49 UTC
Created attachment 81500 [details]
screen capture of second bug
Comment 2 Laurent Lyaudet 2013-06-26 19:51:30 UTC
Created attachment 81501 [details]
xlsx to reproduce the bug
Comment 3 m.a.riosv 2013-06-26 23:56:13 UTC
Lourent, I do not know how the file was created.

1:) There is a split, Menu/Window/Split, disable and half of the issue is solved.
    Where the split was when creating the file?

2:) The column A is hidden, drag to the right the column separator line left to column B header.

Please confirm if this solve the issue.
Comment 4 Laurent Lyaudet 2013-06-27 20:56:14 UTC
(In reply to comment #3)
> Lourent, I do not know how the file was created.
> 
> 1:) There is a split, Menu/Window/Split, disable and half of the issue is
> solved.
>     Where the split was when creating the file?
> 
> 2:) The column A is hidden, drag to the right the column separator line left
> to column B header.
> 
> Please confirm if this solve the issue.

Hi,

Thanks for the reply. 
I noted the version on Windows 7
Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)
then installed latest :
Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2)
to reproduce the bug.



1) You're right removing the split solves the weird display. I'll check tomorrow where the split was originally in the xlsx I recieved. 
Anyway, a split shouldn't look that bad ;) so it doesn't really solves the issue.



2) It solves the issue. I didn't saw there was hidden columns, sorry.
In fact it is easy to unhide column A but it doesn't work well for columns H and I; within a few pixels, you can :
a)- change the width of column G
b)- unhide column I
It doesn't seem possible to unhide H unless you unhide I before.
I don't remember if I tried to unhide yesterday and just a) occured.

I think the ergonomics of hide/unhide column should be improved.
Since we need handles to drag columns limits, I think whenever one or more columns are hidden between two columns, there should be some icon.
Maybe just a small colored circle
                   _
or a triangle like V  (poor ascii art attempt :) )
above the limit between the two visible columns.

You could click this icon to expand a small "popup" of handles for hidden columns.
Without using the "popup", the behavior would be unambiguous :
a)- change the width of column G
Using the "popup" would give more possibilities :
b)- unhide column I
c)- unhide column H

Alternatively, since the limit between G and J is already bold, one could click the limit instead to open the popup (thus no icon would be required).

I have no idea if it can be easily done with current architecture of LibreOffice (with jquery I would say piece of cake :) ).
Let me know what you think of it. I'll fill a feature request if you think it could be done.

Best regards,
    Laurent
Comment 5 m.a.riosv 2013-06-27 21:52:50 UTC
To Hide/Show column(s), there are several options:
- Selecting the column(s) by their header you can right-clik Hide.
- Selecting cell/range with Menu/Format/Column - Hide/Show.

- Selecting column(s) before+after the hidden column(s), right-clik Show, or Menu/Format/Column - Show.

This options do not change the column with.
Comment 6 Laurent Lyaudet 2013-06-29 18:39:30 UTC
Hi,
Sorry for the late answer. I've been busy yesterday evening and today until now.
I did a few experiments yesterday morning with the original xlsx and the situation is more complicated than what I tought.
I'll keep using the two points 1) and 2) of the preceding commentaries, 3) for a new possible feature request and 4) for the possible feature request I talked about last time.

1)There is no split in the original xlsx (none that appears when I open it with Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2) on Windows 7)
But there is a freeze. 
If I empty the xlsx and save it, there is still a freeze but no split.
I see two possibilities :
a) either when opening the xlsx with Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3), a split is imported instead of a freeze. In that case, the split is then saved after emptying the xlsx.
b) or when emptying the xlsx, the freeze is changed into a split and then saved.

Since the display bug did appear only after emptying the xlsx, either the split becomes buggy after emptying (a), or it is created buggy (b).

I'm unable to create a buggy split by hand in the xlsx.
It seems that the buggy split could be created in 4.0.2 but doesn't create in 4.0.4.

The buggy split, once present, is buggy in 4.0.2, 4.0.4, 3.5.7.
I'll add two xlsx attachments to the bug :
- One I created by removing the freeze then emptying. 
- One I created by emptying but keeping the freeze.

These two attachments are useful also for the next point.

2)I felt quite dumb for not seeing that I could unhide column A, but my experiments yesterday gave me hope, since I had no hope to unhide this column ;)
In fact, you can't unhide column A in the original xlsx.
The two attachments obtained by emptying the original xlsx with 4.0.4 have the same property.
I do believe this is somehow linked with the split issue and I smell a nasty bug.
Note that you can unhide the other columns. Only A seems to be special.
A few more elements on that :
- the left limit of B is not bold as it should.
- it is not draggable
- the other methods you mention do not work.
- if you click on the X zone
X|B|C
-
1|
-
2|
and right click unhide on B, all columns are unhided except A.

This last method to unhide all columns could be improved because you can't right click X : you have to click X then right click B or another column.
I know why it is that way, since right clicking 1 instead of B would unhide rows instead of columns.

But I suggest :

3) Split the X zone in 3 parts like this
  __
 | /|
 |/\|
and make all three zones clickable and right clickable:
- right part selects all columns and make it possible to apply actions (from contextual menu or other actions) to all columns
- lower part selects all rows and make it possible to apply actions (from contextual menu or other actions) to all rows
- upper left part selects all columns and rows and make it possible to apply actions (from contextual menu or other actions) to all columns and all rows

4)Regarding my previous possible feature request and the alternatives:
- Selecting cell/range with Menu/Format/Column - Hide/Show.
- Selecting column(s) before+after the hidden column(s), right-clik Show, or Menu/Format/Column - Show.
Both alternatives unhide all columns between G and J.
You can also right click the limit between G and J and choose unhide but this alternative has the same problem of pixel precision than the actual dragging and doesn't permit to unhide H before I.

I think that the possibility to hide/unhide while preserving the width of the columns is not incompatible with a more continuous feature of unhiding (since the continuous feature of hiding already works).
In fact because of the limitations of all the existing methods, there could be two things in the "popup" : 
- handles for the continuous feature and 
- buttons for unhiding with the original width
I'll try to give an idea of the popup :
- two layers : upper layer is for buttons (rectangular), lower layer is for handles (ellipsoids)
    _   _
   |H| |I|
    _   _
   (H) (I)
    \   / (on this line I tried to represent some branch from the ellipsoids to the limit)

Best regards,
   Laurent
Comment 7 Laurent Lyaudet 2013-06-29 18:41:48 UTC
Created attachment 81703 [details]
second xlsx to reproduce the bug
Comment 8 Laurent Lyaudet 2013-06-29 18:42:52 UTC
Created attachment 81704 [details]
third xlsx to reproduce the bug
Comment 9 Laurent Lyaudet 2013-07-01 20:51:15 UTC
Point 3 has been moved in an independant enhancement request : number 66472.
Comment 10 QA Administrators 2015-04-01 14:42:02 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 on a currently supported version of LibreOffice (4.4.1 or later)
   https://www.libreoffice.org/download/

   *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
   *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

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)

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: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Comment 11 Laurent Lyaudet 2015-04-03 18:28:40 UTC
Hi,

The display bug and the "freeze becoming a split bug" seems to be corrected in release 4.4.1.2 on Windows 7.
For the bug with unhidding of column A that is impossible I created a new bug report 90439 after reproducing it.
For the feature request I talked about, I created a separate feature request 90440.

Best regards,
   Laurent Lyaudet