Bug Hunting Session
Bug 76032 - FILEOPEN: shift of cells in a specific xlsx
Summary: FILEOPEN: shift of cells in a specific xlsx
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: Other Linux (All)
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: BSA target:4.3.0 target:4.2.3
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-11 13:35 UTC by Aaron Digulla
Modified: 2014-03-17 09:36 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Excel sheet which can't be opened (6.09 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2014-03-11 13:35 UTC, Aaron Digulla
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Digulla 2014-03-11 13:35:24 UTC
Created attachment 95601 [details]
Excel sheet which can't be opened

The attached Excel sheet should look like this:

Action Plan.Name   Action Plan.Description
------------------+------------------------
Jerry              This is a longer Text.
                   Second line.
                   Third line.

In LO 4.0.2.2, the second column is empty.

In LO 4.2.1, trying to open the file just displays an error. On the console, I see this output:

:1: parser error : Document is empty

^

Note: The error would be more useful if it said *which* document is missing :-)

Operating System: Ubuntu
Version: 4.2.1.1 release
Comment 1 Maxim Monastirsky 2014-03-11 17:19:50 UTC
Hi,

(In reply to comment #0)
> I see this output:
> 
> :1: parser error : Document is empty
> 
> ^
> 
> Note: The error would be more useful if it said *which* document is missing
> :-)
This output isn't related to your problem. You can avoid this output if you'll use the correct extension for that file - which is xlsx.
Comment 2 Maxim Monastirsky 2014-03-11 17:21:26 UTC
Comment on attachment 95601 [details]
Excel sheet which can't be opened

Changed file extension and mimetype.
Comment 3 Julien Nabet 2014-03-11 21:06:28 UTC
On pc Debian x86-64 with 4.2 sources updated some days ago and on master sources updated today I got this:

A1: Action Plan.Name     B1: empty
A2: Jerry                B2: Action Plan.Description
A3: vide                 B3: contains 3 lines: 
                           This is a longer Text.
                           Second line.
                           Third line.
Comment 4 Aaron Digulla 2014-03-12 20:32:45 UTC
> This output isn't related to your problem.

Well, Excel can open the file, even though the extension is wrong.

I would prefer it if the "open file" code wouldn't look at the extension but at the file content.

And the error message should still say which document it's expecting :-) Just saying "There was an error" isn't very useful for anyone.

> [output with updated sources]

Much better but I wonder where A3 and B1 are coming from :-)
Comment 5 Maxim Monastirsky 2014-03-12 21:51:56 UTC
(In reply to comment #4)
> I would prefer it if the "open file" code wouldn't look at the extension but
> at the file content.
That exactly what libreoffice does when you don't specify the format. The output you're seeing is from one of the so-called 'type detection' services. But it's not the problem in your case, because in your case libreoffice can detect that it's xlsx, but it can't actually *open* it, which is a different problem.

> And the error message should still say which document it's expecting :-)
This output is from an external library (libxml), and AFAIK we have no control about it.

As for the bug itself: Under Fedora 20 with 4.2.2.1 I'm getting SIGABRT while opening this spreadsheet. But I'm able to open it with the latest master and 4.2 (just like Julien pointed out). So this problem seems solved.

Now we have another problem - the shift of B1:B2 to B2:B3. I can confirm that it doesn't look like this in Excel 2010 SP2, but like in your original report.
Comment 6 Kohei Yoshida 2014-03-13 21:48:43 UTC
I got this.
Comment 7 Commit Notification 2014-03-13 22:41:28 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

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

fdo#76032: Write test for this.



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 8 Commit Notification 2014-03-13 22:41:40 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

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

fdo#76032: This row index is 1-based whereas our own mnRow is 0-based.



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 9 Commit Notification 2014-03-13 22:58:29 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

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

fdo#76032: This row index is 1-based whereas our own mnRow is 0-based.


It will be available in LibreOffice 4.2.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 10 Kohei Yoshida 2014-03-13 23:02:39 UTC
Fixed in 4.2.4.
Comment 11 Commit Notification 2014-03-17 09:36:57 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-4-2-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=13686e068a057feb395308dfdce6df6717e1e4e6&h=libreoffice-4-2-3

fdo#76032: This row index is 1-based whereas our own mnRow is 0-based.


It will be available already in LibreOffice 4.2.3.

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.