If I anchor a form control (e.g. push button)to "Cell", after closing and then reopening the document, the form control anchor changes to "Page". As a result the form control changes its position. Also, the form control can become smaller each time the document is closed & reopened. I think this bug has occurred in an earlier version of LibreOffice (Bug 45076) but was reportedly fixed. I am definitely using version 4.1.04.
Cannot reproduce using LO 4.1.0.4 under Windows 7 x64. I create a new spreadsheet, insert a pushbutton, anchor it to cell, notice its width and height. After saving and reopening, everything stays correct. Could you provide more details, or a test case?
Wasn't there an issue with anchoring of images, when saved as xls ?
Created attachment 83660 [details] Push Button Screenshots These screenshots show that the push button does change its position and shape after the spreadsheet is reopened.
Expanding on the screenshots I have attached.. When I recreated the bug for the screenshots, the push button did not change from cell to page anchor (sorry!) but are still changing position after reopening. I have therefore changed the title of the bug to reflect this. The screenshots also show that the buttons can change their shape (see page 2 of the screenshots).
Created attachment 83673 [details] Spreadsheet with push button Open the attached spreadsheet: 'Push Button with macro'. You will need to enable macros. The macro inserts a new row each time it is pressed. Press the button to insert about 8 rows (the push button is anchored to 'Cell'). Save & close the spreadsheet. Reopen the file to see if the position of the button has changed.
Steps from Attachment 83660 [details] (page 1) are reproducible with 4.1.0.4 under Win7x64. The position of the pushbutton anchored to cell is not preserved after inserting rows above it. Still cannot reproduce sizing problem. If only you could provide steps to reproduce it as clear as you did for positioning problem! :)
Created attachment 83711 [details] Spreadsheet with several push buttons Regarding the sizing problem of form controls: After further testing, the size of the form controls seem to change after file reopening, if there is more than one form control and rows are inserted above. Open the spreadsheet attachment: 'Spreadsheet with several push buttons'. Use the 'Insert Row' push button to insert 5 rows. Save and close the spreadsheet. On reopening the spreadsheet I found that both the position and size of the push buttons had changed.
OK. Both problems (replacement and resizing) is reproducible with 4.1.0.0.beta1 under Win7x64. Both problems are NOT reproducible with 4.0.4.2 -> regression. Rupert Parsons, thank you for report and detailed instructions with testcases!
Created attachment 86896 [details] correct aligned elements
Created attachment 86897 [details] elements distorted
Hi, I have the same problems described here, resulting in loss of information. (see my screen shots both 67712-a and 67712-b). Another test-case: Start libreoffice spreadsheet, and draw two lines halfway down the screen (using view > tool-bar > drawing > line). Right click one of them and change anchor > to cell. Save, close and reopen Notice the position of the line has changed. The problem did not exist in 4.0.2 but exists in 4.1.1.2 so it is a regression (as stated earlier) Greetz
Created attachment 88319 [details] Documentation distorted with 4.1.2.3 (but OK with 3.6.7.2) This documentation is well displayed with LO 3.6.7.2 but is distorded 4.1.2.3.
Hi, Same problem with our documentation (see file attached) : we used to work with LibreOffice 3.6.7.2 (Fedora 18), but can't migrate to LibreOffice >4.0 (distributed with Fedora 19). If you need more info, feel free to tell me. Thanks, Sébastien
*** Bug 68797 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > *** Bug 68797 has been marked as a duplicate of this bug. *** Hi Gerco, the same moment you declared bug 68797 duplicate to this I added a minimal testcase there. Perhaps this testcase is usefull for you in this situation too. I'am sure that the information from content.xml in the documents structure is not read in carefully and _stored_wrong_ if you save the document. Destroying content is a high priority bug for me. If you need more info please give me a feedback. Thanks in advance! Bernhard
What happens when you save in new version and reopen in old version?
(In reply to comment #16) > What happens when you save in new version and reopen in old version? Sorry, I can't test. (I only use 4.x with need and pride.) But I checked the problem in the contents.xml part of the according .ods file and there the entries were stored with the wrong position. So I'am very sure that it will open wrong with the old version too. (File corruption.) Testfiles (very small) https://bugs.freedesktop.org/show_bug.cgi?id=68797 Comments 6-8 Bernhard
(In reply to comment #17) This means there is Data-Loss and Regression. I will add this bug to the "most annoying bugs" list
*** Bug 70491 has been marked as a duplicate of this bug. ***
Fixed with this patch : https://gerrit.libreoffice.org/#/c/8693/1 (Need for review)
We don't mark a bug fixed until it's actually merged. Proposing a fix on gerrit doesn't count. Plus the patch on gerrit doesn't seem accessible.
(In reply to comment #21) > We don't mark a bug fixed until it's actually merged. Proposing a fix on > gerrit doesn't count. Of course. AFAIAA, I only added a link to another issue (See...) but aparently something went wrong.
please retest under 4.2.x if bug still present move it to mab4.2 list since 4.1.x is EOL
(In reply to comment #23) > please retest under 4.2.x > if bug still present move it to mab4.2 list since 4.1.x is EOL Op of Bug 70491 (dup) here. Unfortunately I cannot confirm that the problem has been fixed, sorry. Same behaviour as before: - draw a line - change anchor to "Cell" instead of page - save and close document - open document - the line has moved: the leftmost endpoint of the line is now in column A, the topmost endpoint of the line is now in row 1. Version: 4.2.3.3 Build ID: 4.2.3.3 Arch Linux build-3 I don't know enough about the bug reporting system to touch anything except my reports :) So I did not move anything around.
Isn't https://bugs.freedesktop.org/show_bug.cgi?id=78396 the same?
if we think it's a duplicate let's consider that a bibisect is available here: https://bugs.freedesktop.org/show_bug.cgi?id=78396#c4
f6010f35e4b7789ef7bafcebc9b812b8a5492e26 is the first bad commit commit f6010f35e4b7789ef7bafcebc9b812b8a5492e26 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Oct 16 11:07:50 2013 +0000 source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582 commit 5da10275a7475efdbfd9de14ea58cf8f4c6c1582 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Fri Mar 1 17:09:45 2013 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Fri Mar 1 17:18:29 2013 +0100 Related rhbz#915743: Abort UCB call from SvtMatchContext_Impl::Stop ...as otherwise the SvtMatchContext_Impl thread can continue to run for arbitrarily long, and the other thread calling Stop() and join() will block. However, especially the WebDAV UCP does not properly support aborting commands, see 260afe56fd6b2f34de8290f3cdb7d1df5b88f8a8 " neon commands cannot be aborted", so this is not yet enough to actually fix rhbz#915743 "thread deadlock/slow join in insert->hyperlink in impress." Change-Id: I0da899f824763e1b3d19bb5b38d906feb690b623 :100644 100644 fd22aadcebcf1ca20b6c2fcdb9e135deeb9b5885 8a0f14e1bb71d7ecdf8086c62e9769bb7f2d09b8 M autogen.log :100644 100644 5af869ab53b50329a270e7d4e2587f802bf68afb 8519bf956c5e06a85818d380070eedc0ef846790 M ccache.log :100644 100644 63cd7351c9d6feb098661a5783d51bb172d8a306 33abac29aad7182260562465482b493d94b78a83 M commitmsg :100644 100644 e9ea867065a69fa4f0fbbb5c2abb40baeeabd307 21fc5294b2cb922862b78327b6b8a3cd953f38b5 M dev-install.log :100644 100644 4c087a5ff52a8cef08f31417ac650666b1d9d0af c1cc87465560a589137349c81641a62968242386 M make.log :040000 040000 ece742cbaf9101d015210ea8da6c00ad7a4457c7 9ff9cbceea1fe6b0ad1b17fe9068b2c8e32a6cbb M opt # bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a git bisect good 8092559c5013969ebda017d79200463b9b975038 # bad: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946 git bisect bad 0270ef1b76a6de423b30f7927362cc01c1a0fc38 # bad: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2 git bisect bad aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1 # bad: [c2f6a4b268225aae5000e648dbcd7accd3e8da49] source-hash-34847f1cf7538c333e9b8700eb4012ae358644a6 git bisect bad c2f6a4b268225aae5000e648dbcd7accd3e8da49 # good: [fc4368c4aca1863da8848a58ec2ba1d41f4e43ac] source-hash-6978ddbf4738b4c53b9d2edbe6d5ad6a061d0d0f git bisect good fc4368c4aca1863da8848a58ec2ba1d41f4e43ac # bad: [c1950395cd3f1daccf879496a96cfa5fa19af592] source-hash-ee53857e984fea54b7dc08b99079b38766f0b796 git bisect bad c1950395cd3f1daccf879496a96cfa5fa19af592 # bad: [3399cdc9147715ca26b723006b2f2a10de4ad0a3] source-hash-b15f095293c6127ecaef2f0fa3a1683e72392835 git bisect bad 3399cdc9147715ca26b723006b2f2a10de4ad0a3 # good: [3b5aed6892700c71fc0d7490dfd57ef968189db4] source-hash-ba446dd58a4ad324d242afcd5b28d3b4dff5a881 git bisect good 3b5aed6892700c71fc0d7490dfd57ef968189db4 # bad: [f6010f35e4b7789ef7bafcebc9b812b8a5492e26] source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582 git bisect bad f6010f35e4b7789ef7bafcebc9b812b8a5492e26 # first bad commit: [f6010f35e4b7789ef7bafcebc9b812b8a5492e26] source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582
*** Bug 78396 has been marked as a duplicate of this bug. ***
note that duplicate bug 67712 is bibisected too
(In reply to comment #29) > note that duplicate bug 67712 is bibisected too Ahum ... bug 78396 obviously
Its rather unlikely to be Stephan's commit (based on the description) - I imagine there is a calc commit in the last range of badness there - bibisect doesn't get it down to the last commit - so it'd be good to look at that.
(In reply to Michael Meeks from comment #31) > Its rather unlikely to be Stephan's commit (based on the description) - I > imagine there is a calc commit in the last range of badness there - bibisect > doesn't get it down to the last commit - so it'd be good to look at that. If I read the bibisect output well, the last found good one was http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba446dd58a4ad324d242afcd5b28d3b4dff5a881 2013-01-23 16:16:45 (GMT) and the first bad one http://cgit.freedesktop.org/libreoffice/core/commit/?id=5da10275a7475efdbfd9de14ea58cf8f4c6c1582 2013-03-01 16:18:29 (GMT) Does that mean that the code must have been added somewhere in those fen minutes?
s/fen/few
Bjoern - quick question if you have a minute - I'm struggling to understand the bibisect output here. Of course, the ideal would be that it gives you a simple pair of source hashes and a range, rather than 'first bad'. Is it really these 2000 commits we isolate it to? or - am I missing something ? git log ba446dd58a4ad324d242afcd5b28d3b4dff5a881..5da10275a7475efdbfd9de14ea58cf8f4c6c1582 --oneline Thanks! =)
*** Bug 86280 has been marked as a duplicate of this bug. ***
First bad commit is: commit 2b1aa949539d2fcbb3d349be3c279996630d83fc Author: Noel Power <noel.power@suse.com> Date: Tue Feb 19 17:29:32 2013 +0000 fdo#56276 - resize/reposition rotated shapes in a sensible way Change-Id: Ifa4f848da21838591daa1f57fb42dfd3f4fa8044 I used lo-daily-till41 bibisect repo made by Miklos, which gave a range of 83 commits, instead of 2240. (see https://bitbucket.org/vmiklos/lo-daily-till41)
(In reply to Andras Timar from comment #36) > First bad commit is: > commit 2b1aa949539d2fcbb3d349be3c279996630d83fc > Author: Noel Power <noel.power@suse.com> > Date: Tue Feb 19 17:29:32 2013 +0000 > > fdo#56276 - resize/reposition rotated shapes in a sensible way > > Change-Id: Ifa4f848da21838591daa1f57fb42dfd3f4fa8044 > > I used lo-daily-till41 bibisect repo made by Miklos, which gave a range of > 83 commits, instead of 2240. (see > https://bitbucket.org/vmiklos/lo-daily-till41) Seems I'm unable to query good Bugzilla results. Today I did this bibisect and bisecting independendly and came to the same result. I actually reverted the "new" part of the patch, which solved the problem but brought back bug 56276. I guess the reopened bug 53228 is also a duplicated, from the look at the PDFs.
(In reply to Jan-Marek Glogowski from comment #37) > Seems I'm unable to query good Bugzilla results. Today I did this bibisect > and bisecting independendly and came to the same result. I actually reverted > the "new" part of the patch, which solved the problem but brought back bug > 56276. I guess the reopened bug 53228 is also a duplicated, from the look at > the PDFs. IMO bug 56276 is much less severe than this 67712 :) So If I'm given a choice..
(In reply to Beluga from comment #35) > *** Bug 86280 has been marked as a duplicate of this bug. *** confirmed in a recent 4.3.x release. moving bug to mab4.3 list since 4.3.x is EOL
*** Bug 87150 has been marked as a duplicate of this bug. ***
Created attachment 110902 [details] Spreadsheet with graphics elements Posting the example here since bug #87150 has been marked as a duplicate of this one. Please notice that with current Apache OOo (v4.1.1) I can correctly display the file (I used that application for sanitizing the file). Thanks
Created attachment 113037 [details] unit test The attached unit test shoud pass. I don't know, if it is all about it, but it is a good start.
CC-ing the expert :) @Markus, this is what we're talking about. See the unit test.
*** Bug 81838 has been marked as a duplicate of this bug. ***
*** Bug 77522 has been marked as a duplicate of this bug. ***
Hi, Same issue in LO 4.3.6.2 Windows, ubuntu 32 & 64bits ! Any ideas about how to fix will be welcome. Thanks.
Please don't update the version - it's the oldest version that we have reproduced the issue - just leave a comment saying that the bug is still around on a specific version and OS. Thanks
*** Bug 87650 has been marked as a duplicate of this bug. ***
Henry pushed a fix to gerrit: https://gerrit.libreoffice.org/#/c/15523/ It'd be great to test it vigorously as/when it makes it to master =)
Lubuntu 14.04LTS 64bit Version: 5.0.0.0.alpha1+ Build ID: 3a96d8ead86dc210085f09076fd270f247442f0a TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-26_02:57:10 Locale: en_NZ Form Controls (SUCCESS): I drew a push button at 140% zoom, covering C3 to C4 anchored it to 'cell' C3 save & closed the ods on reopening the button is still anchored to C3 Draw Objects (FAIL): I drew a line from the middle of C6 to the middle of D6 anchored it to 'cell' C6 save & closed the ods on reopening the line was running from the middle of A1 to B1
(In reply to reporter_of_bugs from comment #50) > > Form Controls (SUCCESS): > I drew a push button at 140% zoom, covering C3 to C4 > anchored it to 'cell' C3 > save & closed the ods > on reopening the button is still anchored to C3 > additionally: Form Controls (FAIL): 1. after another push button of the same size (B7-B8), anchored to B7 2. inserting 2 rows above row 2 3. saving and reopening the ods both the push buttons are 50% of their previous height, i.e 1 row
(In reply to reporter_of_bugs from comment #51) > additionally: > Form Controls (FAIL): > 1. after another push button of the same size (B7-B8), anchored to B7 > 2. inserting 2 rows above row 2 > 3. saving and reopening the ods > > both the push buttons are 50% of their previous height, i.e 1 row Reproduced this and comment 50. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64) Build ID: f0edb677f09ad338e22ac3b5d91497b4479e0b3c TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-27_01:54:20 Locale: fi_FI
(Tried with the next day's build) Version: 5.0.0.0.alpha1+ Build ID: f0edb677f09ad338e22ac3b5d91497b4479e0b3c TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-27_00:34:40 Locale: en_NZ I have reproduced the above errors as before and also the line drawn disappeared from the spreadsheet when I opened it for the 3rd time, at least from the cells A1:AC100 or so.
Henry Castro committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=487880b6882ec01c1b4679eae60bec484272a86b Resolves tdf#67712 form controls and draw objects It will be available in 5.1.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.
Henry Castro committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dabe4ad3bf21b6b6c9eadbd7e78262a1f59af771&h=libreoffice-5-0 Resolves tdf#67712 form controls and draw objects It will be available in 5.0.0.0.beta2. 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.
@henri: thanks a lot!
I have test in Version: 5.1.0.0.alpha1+ Build ID: 6c1cabe677f5eb24b465dd6e316c8c66df64bb29 whit arrow and is great, thanks! Is it possible come available in LO 4.4.4?
Henry Castro fixed it.
(In reply to Andras Timar from comment #58) > Henry Castro fixed it. Is It alzo fixed in LO4.4.4.0?
No it is only fixed in LibreOffice 5 - it might be backported (depending on the complexity of the patch along with the desire of the developer). If so you'll see target 4.4.x in whiteboard. Thanks!
Thanks Henry for the patch. It's a very annoying bug with data and contentlost, so... i reopen it because i think it must be backported in 4.4.x.
@Denis this is not the correct procedure I revert status to FIXED
@tommy Ok, ... and sorry. Could you please, tell me what is the correct procedure to ask the backport to 4.4.x ? (EOL : November 18, 2015)
(In reply to Denis RADWAN from comment #63) > @tommy > Ok, ... and sorry. > > Could you please, tell me what is the correct procedure to ask the backport > to 4.4.x ? (EOL : November 18, 2015) The correct procedure is to ask and not change status to reopened :)
Thx Beluga and so... this is an request ; ) Due to the loss of data or content, and the fact that this may be blocking for certain uses. It would be important to backport the patch in version 4.4
(In reply to Denis RADWAN from comment #65) > ... > It would be important to backport the patch in version 4.4 added backportRequest:4.4 to whiteboard let's see if Henry Castro thinks this is technically feasible
*** Bug 91979 has been marked as a duplicate of this bug. ***
(In reply to tommy27 from comment #66) > let's see if Henry Castro thinks this is technically feasible Henry Castro does not have Bugzilla account :-P Here is the backport in gerrit: https://gerrit.libreoffice.org/16280
Henry Castro committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c02e1892ad87aa81e29b5642b16db3f4c128418&h=libreoffice-4-4 Resolves tdf#67712 form controls and draw objects It will be available in 4.4.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.
removing "backportrequest", was already done
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
https://www.jualtasmurahbbs.com/ toko tas murah bandung ranselvintage merupakan toko tas online yang menjual tas ransel murah dan tas vintage untuk anak anak perempuanan brand lokal asli jual tas vintage murah tas export online harga murah bisa hasil https://www.jualtasmurahbbs.com/category/tas-sekolah-anak/ grosir tas sekolah murah dan bagus backpack wanita bagus backpack wanita cantik backpack wanita handbag wanita backpack wanita laptop backpack wanita terbaru leave a comment grosir tas jual tas harga tas grosir https://www.jualtasmurahbbs.com/category/kipling/ toko tas kipling dengan slot laptopmurahonline terbaru jual tas laptop murah tas laptop murah surabaya grosir tas laptop surabaya produsen tas laptop jual tas ransel laptop surabaya dapatkan tas laptop dengan https://www.jualtasmurahbbs.com/category/tas-ransel-wanita/ grosir tas ransel wanita salah satu aksesoris utama bagi pria dan wanitasiapa saja pasti akan suka menggunakan tas untuk bepergian atau keperluan sehari hari lainnya karena tas adalah adalah aksesoris yang serba guna https://www.jualtasmurahbbs.com/category/tote-bag/ tote bag terbaru travel bag surabaya grosir handbag grosir tas pabrik tas murah tas pabrik tas grosir terbaru grosir handbag grosir tas agen tas pabrik tas konveksi tas home industri tas souvenir tas gambar tas grosir https://www.jualtasmurahbbs.com/category/cath-kidston/ cath kidston bandung kain spundbond di palembang souvenir ulang tahun anak unik di palembang tote bag blacu polos sablon di palembang tas kanvas di palembang tas promosi di palembang souvenir tas laundry di https://www.jualtasmurahbbs.com/category/anello/ toko tas anello murah di bandung hingga bisa memuat lebih banyak barang di dalamnya tas model ini sangat disukai beberapa wanita karena mempunyai kompartemennya yg luas goodie bag printing souvenir ulang tahun anak murah https://www.jualtasmurahbbs.com/category/jansport/ grosir jual tas jansport murah there are no reviews yet be the first to review tote bag dog jakarta cancel reply your email address will not be published required fields are marked your rating tas fossil terbaru model tote bag kw