Hello, After having made some rechearch, I did not find any report concerning this bug. Several buttons of my spreadsheet file disappeared. Steps to reproduce. 1. Open a spreadsheet file 2. Place some buttons, for example assigned to the other sheets of the file or to an external file. 3. Save the document 4. Close completly libreoffice 5. Reopen the file. The buttons can still be there or have disappeared partially or all of them. In fact, this can happen at the first attempt or later when the file is edited; Hope that this post is not a duplicate. If ever it's the case, sorry for it. Else, hope that this post will help to make the forcoming version better. Best regards Bunty
Can you attach a document which displays this behavior? Is there any way you can submit one that is good and one that is not? (Is this a regression from previous versions of LibreOffice)? Marking as NEEDINFO, once you provide a bit more detail can you open the bug up as UNCONFIRMED and I'll take a look at it. Thanks for your patience and understanding
Created attachment 73014 [details] Original file open with Libreoffice 3.6.2.2 under UBUNTU
Created attachment 73015 [details] Modified file open with Libreoffice 4.0.0.1 from Libreoffice site
Hello, Hear one of my numerous file affected with this bug. You'll notice that all buttons in "Menu" & "Perso" have disappeared. Hope that this can help further. Bunty
Sorry fr Comment 5 & 6. Misuse of the site. Bunty
I tried my best, but I can't reproduce this. I opened the attached in Comment 2, resaved it via "Save As", closed & reopened it. All the buttons are there, including the ones on the first sheet. Tried both my own 4.0 build and the SUSE packaged 4.0 RC1. The same result.
Hello Mr Kohei Yoshida, I tried myself the same thing and I infact get the same result as you. Please try this. 1. Select the sheet "Lycée" 2. Write something in a cell 3. Save 4. Close everything. 5. Reopen the file You'll notice that all buttons in "Menu" have disappeared, 2 buttons in "Lycée" are colored, font for the text for the buttons in "La Fac" have changed and only 7 button out of 8 have disappeared. Hope that you'll be able to reproduce. Else feel free to as question Thanks Bunty
I am unable to reproduce the issue with those instructions.
I don't know what to say. I got this bug since I installed Lib4. I'll try on another machine and let you know as sson as possible. BS
I tried on another machine, I got almost the same result. Every buttons in "Menu" disappeared. I can't say why you can't reproduce this bug. Infact, I need you help to underdstand. Thanks SB
I'm going to cc Markus & Eike to see if one of them can reproduce @Markus & Eike - sorry for CC'ing you but can you take a look at this one. Both Kohei and I were unable to reproduce but user has verified on two machines. If this can be confirmed I'd like to get it out of UNCONFIRMED status. Thanks for helping!
I can reproduce this using instructions from comment 9. At first it seemed I didn't reproduce, but: make sure you check "Menu" and "Perso" *tabs*, not buttons. The buttons completely disappear from Menu tab and some of the buttons disappear from Perso tab. Also, maybe it depends on which cell you enter data in, I didn't change currently selected cell (it was at right part of screen nearly centered vertically). If any questions, I'm willing to provide more info (maybe a screencast).
I'm glad to see that someone has been able to reproduce. I've been worried that I'll be the only one affected by this issue. Hope that you'll find a patch for it. Thanks BS
I could reproduce this in a 4-0 non-dbgutil build, but not in a master --enable-dbgutil build. But when loading already the original document in dbgutil there are lots of warnings: warn:svx.sdr:22091:1:/build/libo/core/svx/source/svdraw/svdobj.cxx:2935: SdrObject::impl_setUnoShape: still having impl. pointer to dead object! warn:legacy.osl:22091:1:/build/libo/core/sc/source/core/data/drwlayer.cxx:912: Start/End falsch in ScDrawLayer::GetPrintArea warn:sc:22091:1:/build/libo/core/sc/source/filter/xml/xmlsubti.cxx:223: more columns than fit into SCCOL warn:legacy.tools:22091:1:/build/libo/core/xmloff/source/draw/ximpshap.cxx:1705: draw:control without a form:id attribute! This smells..
Created attachment 73189 [details] Screenshot to illustrate the problem I doscovered another problem. If I modify and then save the file in the "Menu" tab, I can't reopen the file. See screenshot joined. Steps to reproduce 1. Open the file (comment 2;Attachment #73014 [details]). 2. Write something in tab "Menu". 3. Save the file. 4. Close everything. 5. Reopen the file. Here the popup saying that I can no more open the file. Hope that someone can reproduce the bug.
> I doscovered another problem. If I modify and then save the file in the > "Menu" tab, I can't reopen the file. See screenshot joined. Can't reproduce with current 4-0 code. And please, for different problems submit different bugs, thanks.
Side note (In reply to comment #16) > warn:sc:22091:1:/build/libo/core/sc/source/filter/xml/xmlsubti.cxx:223: more > columns than fit into SCCOL This was probably unrelated and fixed with http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b1f201b58b392a372ffc9070d41844997a2ec7d Other gazillion of warnings remain.
(In reply to comment #18) > > I doscovered another problem. If I modify and then save the file in the > > "Menu" tab, I can't reopen the file. See screenshot joined. > > Can't reproduce with current 4-0 code. And please, for different problems > submit different bugs, thanks. Sorry for this but I considered that this bug can be related to the reported bug. Anyway, it has obviously been fixed. Just want to help. BS
Created attachment 73448 [details] Bibisect40 log
I'm going to take a look ( for my sins ) at this.
it's reproducible for me on 4.0 not on master
@Noel: Reverting c4e649f0cd013e86adbd794859bcc3cb9ee3aa61 "Sync draw object to calc grid for better alignment when zooming" (plus a few later introduced uses of SetGridOffset() to make it build) of the bibisect range the bug disappears. An idea what may be different in master that the bug does not occur there? I didn't spot anything obvious on a first glance. If it's not just dbgutil that makes it disappear..
(In reply to comment #24) > @Noel: > Reverting c4e649f0cd013e86adbd794859bcc3cb9ee3aa61 "Sync draw object to calc > grid for better alignment when zooming" (plus a few later introduced uses of > SetGridOffset() to make it build) of the bibisect range the bug disappears. > An idea what may be different in master that the bug does not occur there? I > didn't spot anything obvious on a first glance. If it's not just dbgutil > that makes it disappear.. hmm no, initially when I started to look at this earlier today I suspected the zoom patch but then because it was working on master kinda dismissed it. I can't think of any patches that are relevant to this on master that are not on 4.0. Anyway sofar I have only got as far as reducing the test document to something manageable ( and I am reverting that patch locally too ) I must learn about bitbisect :-) ( I'm afraid I didn't understand the bitbisect info attached earlier ) Of course valgrind doesn't show any problem so it seems that for some reason some underlying Sdr(Uno?)Object or whatnot is getting released. Sofar I don't see how the zoom patch would affect that ( but who knows in this twisted libreoff-iverse ) Anyway I will chase if for a while and see if I get anywhere
adding regression keyword
> Anyway I will chase if for a while and see if I get anywhere after working backwards through the export it looks like http://cgit.freedesktop.org/libreoffice/core/commit/?id=d158a09e56e3944458d63a6c572f60dbe4632dad fixes the problem ( but perhaps hides the root cause ). Although the zoom patch seems to introduce this problem, I don't yet see how :-/, Anyway I will continue for a while and try to find where this happens and hopefully find the real root cause ( if it exists )
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bdb66834887ec58cd9c602841c185a6629b13d6b don't use ScDrawLayer::GetObjDataTab to get Anchor fix for fdo#59325 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.
(In reply to comment #28) > Noel Power committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=bdb66834887ec58cd9c602841c185a6629b13d6b > > don't use ScDrawLayer::GetObjDataTab to get Anchor fix for fdo#59325 > > > > 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. I'll wait till the release of the RC2 version of LibO4.0 to test and give you a feedback BS
(In reply to comment #29) > > I'll wait till the release of the RC2 version of LibO4.0 to test and give > you a feedback > > BS It's pushed to 4.1 branch, not 4.0. AND they are already building for RC2 (string freeze was 2 days ago), so if it's pushed now ... It will not be available in RC2 at all. Maybe will Noel push it to 4.0 later this week, so it'll be available in RC3, but let's wait in patience and let Noel decide what to do/next steps etc :-). Kind regards, Joren
(In reply to comment #30) > (In reply to comment #29) > > > > I'll wait till the release of the RC2 version of LibO4.0 to test and give > > you a feedback > > > > BS > > It's pushed to 4.1 branch, not 4.0. AND they are already building for RC2 > (string freeze was 2 days ago), so if it's pushed now ... It will not be > available in RC2 at all. Maybe will Noel push it to 4.0 later this week, so > it'll be available in RC3, but let's wait in patience and let Noel decide > what to do/next steps etc :-). > > Kind regards, > Joren at the same time as the push to master I requested a review for 4-0 via gerrit ( https://gerrit.libreoffice.org/#/c/1828/ ) Note: only fixes from 4-0 can be cherry-picked to 4-0-0 ( rc? ) anyway I poked the dev list with this as well (since it seems gerrit didn't do the auto-mailing to the list for some reason )
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=a6433b4a9c053b7088d52b216c7d7cf8d9cdfcd7&h=libreoffice-4-0 don't use ScDrawLayer::GetObjDataTab to get Anchor fix for fdo#59325 It will be available in LibreOffice 4.0.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.
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-4-0-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cfd69f75cf50a8730076346ea8db54f2094a5d13&h=libreoffice-4-0-0 don't use ScDrawLayer::GetObjDataTab to get Anchor fix for fdo#59325 It will be available already in LibreOffice 4.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.
Looks like this should be closed then - thanks Noel ! :-)