Bug 62729 - Cell (range) name lost after FILESAVE after other sheet has been deleted
Summary: Cell (range) name lost after FILESAVE after other sheet has been deleted
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other All
: medium critical
Assignee: Noel Power
URL:
Whiteboard: target:4.2.0 target:4.1.1 target:4.0.5
Keywords:
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2013-03-25 15:53 UTC by Andrew Beattie
Modified: 2013-08-05 14:05 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Kit (11.55 KB, application/zip)
2013-03-25 16:37 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Beattie 2013-03-25 15:53:18 UTC
Tested against latest release version (4.0.1.2) on OSX and Windows.

To reproduce:

Open new spreadsheet
Add new worksheet (sheet2)
In Sheet2, give cell A1 a name, such as "somename".
In sheet2, give cell A1 a value, such as 123.
Go to sheet1.  In cell A1, enter "=somename".  Confirm that this works as expected and shows 123

Now delete sheet1.

Observe that cell A1 in the remaining worksheet (sheet2) is still correctly named "somename"

Save the spreadsheet.

Re-open the spreadsheet.

The cell A1 in the remaining worksheet (Sheet2) is no longer named.
Comment 1 Rainer Bielefeld Retired 2013-03-25 16:37:19 UTC
Created attachment 77009 [details]
Test Kit

[Reproducible] with attached "newsample4012.ods" and server installation of "LibO  4.0.1.2 release   -  German UI / German Locale  [Build ID: 84102822e3d61eb989ddd325abf1ac077904985)]"  {tinderbox: @6, pull time  2013-02-28 08:53(?)} on German WIN7 Home Premium (64bit) with newly created user profile ….\LibreOffice\4012\

This bug only appears if I follow exactly reporter's instructions. I also tried a document created with LibO 3.6.6.1 and some smaller differences (3 sheets, 2 ranges), and the bug was not reproducible for me. We should do some more research what conditions are necessary to reproduce the bug.
Comment 2 Andrew Beattie 2013-03-25 16:57:49 UTC
It is significant that the sheet being deleted is in front of the sheet with the named cells.

My knowledge of the internals of the spreadsheet structure is poor but I understand that internally, the worksheets are referenced primarily by index number (starting from zero) rather than name.  Thus I think that the named range is referencing worksheet index number 1.  This is not being updated when worksheet 0 is deleted and thus the range ends up pointing to a worksheet which has been deleted and is therefore not saved.

In my application, I have a data worksheet with nearly 100 named ranges and a macro which creates many worksheets to the left of these.  When the macro-created worksheets are deleted, I loose all my named ranges :-(

For the convenience of my users, I want to keep the macro-generated worksheets (which they use) on the left and the source data worksheets (which they never look at) way off to the right.
Comment 3 Rainer Bielefeld Retired 2013-03-25 16:59:46 UTC
I did some more tests with "newsample4012.ods":

Already [Reproducible] with 
* server installation of "LibreOffice 3.5.7.2  Spanish UI/German Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) 

Was still ok with  
* Server Installation of  "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) 

So it seems this one came up with 3.5?

@Andrew Beattie:
Please add info concerning your OS.
Can you try to find some additional conditions what switch the bug on or off?
Comment 4 Andrew Beattie 2013-03-25 17:08:29 UTC
Tested against latest release version (4.0.1.2) on:
OSX 10.8.2
MS Windows 7 Professional SP1
Comment 5 Andrew Beattie 2013-03-25 17:17:48 UTC
I notice that the structure of named ranges contains both:

a) The address of the range ("Sheet2.A1"), which does not change.

b) A cell address structure com.sun.star.table.CellAddress. Before deleting Sheet1, this would be:

.Sheet=1
.Column=0
.Row=0

After the deletion of sheet1, this should be:

.Sheet=0
.Column=0
.Row=0

How can we check that this has changed correctly?
Comment 6 Rainer Bielefeld Retired 2013-03-25 17:38:12 UTC
Major because bug damages documents.

Already reproducible with LibO 3.5.1.2

@Spreadsheet Team
Please add Witeboard tag “bibisectrequest” if you think that a bibisect result can ease your work.
Please change  Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
Comment 7 Kevin Suo 2013-07-23 01:42:06 UTC
Still Reproducible in LibreOffice 3.6.7 and 4.1.0 RC3.
This happens in ODS file, courses data loss, so I change Importance to "critical".
Comment 8 Michael Meeks 2013-07-24 20:01:27 UTC
Targetting to correct version's MAB list then - thanks !
Comment 9 Noel Power 2013-07-25 16:13:41 UTC
I guess I can take a look at this
Comment 10 Commit Notification 2013-07-26 12:20:01 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "master":

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

fix for fdo#62729 reference pos can point to non existing table



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 11 Commit Notification 2013-07-26 12:20:24 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "master":

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

unit test for fdo#62729



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 12 Commit Notification 2013-07-26 17:02:54 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

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

fix for fdo#62729 reference pos can point to non existing table


It will be available in LibreOffice 4.1.1.

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 13 Eike Rathke 2013-07-26 17:08:31 UTC
@Noel:
Could you backport this to 4-0? sc/qa/unit/subsequent_export-test.cxx doesn't know loadDoc(). We could of course also only cherry-pick b5fffdb8d0438a2fe933a5742d41fe50a14b71f3 without the unit test.
Comment 14 Noel Power 2013-07-29 08:46:37 UTC
(In reply to comment #13)
> @Noel:
> Could you backport this to 4-0? sc/qa/unit/subsequent_export-test.cxx
> doesn't know loadDoc(). We could of course also only cherry-pick
> b5fffdb8d0438a2fe933a5742d41fe50a14b71f3 without the unit test.

yup didn't forget about this just I had no up to date local build of 40 ( should be there now ) hmm hopefully I can put some variant of the test there ( I can no longer track the differences between the unit test support between branches ) anyway I'll see what can be done quickly ( if not like you say I think cherrypicking the fix without the test will do )
Comment 15 Commit Notification 2013-07-30 10:32:24 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

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

fix for fdo#62729 reference pos can point to non existing table


It will be available in LibreOffice 4.0.5.

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 16 tommy27 2013-08-05 14:05:14 UTC
I confirm the bug is fixed in Version: 4.2.0.0.alpha0+
Build ID: aa5683e18de07c9e86325595ead4574efa685c3a
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_00:00:18

tested on Win7 64bit