Bug 67712 - form controls and draw objects anchored to cell but changes position after reopening
Summary: form controls and draw objects anchored to cell but changes position after re...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0 all versions
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: lhm-limux target:5.1.0 target:5.0.0.0...
Keywords: bibisected, bisected, regression
: 68797 70491 77522 78396 81838 86280 87150 87650 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2013-08-03 13:25 UTC by Rupert Parsons
Modified: 2018-11-25 07:44 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
Push Button Screenshots (595.45 KB, application/vnd.oasis.opendocument.text)
2013-08-05 12:26 UTC, Rupert Parsons
Details
Spreadsheet with push button (19.94 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-08-05 16:43 UTC, Rupert Parsons
Details
Spreadsheet with several push buttons (20.40 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-08-06 11:15 UTC, Rupert Parsons
Details
correct aligned elements (36.96 KB, image/png)
2013-10-01 11:02 UTC, Gerco-Kees
Details
elements distorted (62.43 KB, image/png)
2013-10-01 11:02 UTC, Gerco-Kees
Details
Documentation distorted with 4.1.2.3 (but OK with 3.6.7.2) (47.77 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-10-29 18:36 UTC, Sébastien LEFEVRE
Details
Spreadsheet with graphics elements (20.18 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-12-16 11:17 UTC, Mau
Details
unit test (17.29 KB, patch)
2015-02-01 22:36 UTC, Andras Timar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rupert Parsons 2013-08-03 13:25:21 UTC
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.
Comment 1 Mike Kaganski 2013-08-03 13:34:31 UTC
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?
Comment 2 Cor Nouws 2013-08-03 14:38:04 UTC
Wasn't there an issue with anchoring of images, when saved as xls ?
Comment 3 Rupert Parsons 2013-08-05 12:26:54 UTC
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.
Comment 4 Rupert Parsons 2013-08-05 12:38:13 UTC
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).
Comment 5 Rupert Parsons 2013-08-05 16:43:25 UTC
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.
Comment 6 Mike Kaganski 2013-08-05 21:41:37 UTC
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! :)
Comment 7 Rupert Parsons 2013-08-06 11:15:07 UTC
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.
Comment 8 Mike Kaganski 2013-08-07 00:24:07 UTC
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!
Comment 9 Gerco-Kees 2013-10-01 11:02:16 UTC
Created attachment 86896 [details]
correct aligned elements
Comment 10 Gerco-Kees 2013-10-01 11:02:55 UTC
Created attachment 86897 [details]
elements distorted
Comment 11 Gerco-Kees 2013-10-01 11:07:52 UTC
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
Comment 12 Sébastien LEFEVRE 2013-10-29 18:36:05 UTC
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.
Comment 13 Sébastien LEFEVRE 2013-10-29 18:40:44 UTC
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
Comment 14 Gerco-Kees 2014-01-28 13:03:33 UTC
*** Bug 68797 has been marked as a duplicate of this bug. ***
Comment 15 Bernhard Schiffner 2014-01-28 13:27:56 UTC
(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
Comment 16 Gerco-Kees 2014-01-28 13:34:34 UTC
What happens when you save in new version and reopen in old version?
Comment 17 Bernhard Schiffner 2014-02-03 14:38:55 UTC
(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
Comment 18 Gerco-Kees 2014-02-03 20:00:48 UTC
(In reply to comment #17)

This means there is Data-Loss and Regression. I will add this bug to the "most annoying bugs" list
Comment 19 Mohamed-Ali BEN MANSOUR 2014-03-05 12:46:09 UTC
*** Bug 70491 has been marked as a duplicate of this bug. ***
Comment 20 Mohamed-Ali BEN MANSOUR 2014-03-21 13:14:30 UTC
Fixed with this patch :
https://gerrit.libreoffice.org/#/c/8693/1

(Need for review)
Comment 21 Kohei Yoshida 2014-04-08 22:07:23 UTC
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.
Comment 22 Cor Nouws 2014-04-09 07:16:33 UTC
(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.
Comment 23 tommy27 2014-05-05 21:29:56 UTC
please retest under 4.2.x 
if bug still present move it to mab4.2 list since 4.1.x is EOL
Comment 24 Ekki 2014-05-06 20:45:53 UTC
(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.
Comment 25 Cor Nouws 2014-05-29 21:45:38 UTC
Isn't https://bugs.freedesktop.org/show_bug.cgi?id=78396 the same?
Comment 26 tommy27 2014-05-30 01:04:51 UTC
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
Comment 27 Joel Madero 2014-05-30 02:11:07 UTC
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
Comment 28 Cor Nouws 2014-09-30 20:06:26 UTC
*** Bug 78396 has been marked as a duplicate of this bug. ***
Comment 29 Cor Nouws 2014-09-30 20:07:01 UTC
note that duplicate bug 67712 is bibisected too
Comment 30 Cor Nouws 2014-09-30 20:09:34 UTC
(In reply to comment #29)
> note that duplicate bug 67712 is bibisected too

Ahum ... bug 78396 obviously
Comment 31 Michael Meeks 2014-11-20 10:48:39 UTC
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.
Comment 32 Cor Nouws 2014-11-20 12:08:04 UTC
(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?
Comment 33 Cor Nouws 2014-11-20 12:08:19 UTC
s/fen/few
Comment 34 Michael Meeks 2014-11-20 12:48:21 UTC
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! =)
Comment 35 Buovjaga 2014-11-20 13:11:16 UTC
*** Bug 86280 has been marked as a duplicate of this bug. ***
Comment 36 Andras Timar 2014-11-20 17:34:52 UTC
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)
Comment 37 Jan-Marek Glogowski 2014-11-28 21:49:47 UTC
(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.
Comment 38 Cor Nouws 2014-12-01 15:16:35 UTC
(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..
Comment 39 tommy27 2014-12-08 09:16:48 UTC
(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
Comment 40 Cor Nouws 2014-12-09 20:49:46 UTC
*** Bug 87150 has been marked as a duplicate of this bug. ***
Comment 41 Mau 2014-12-16 11:17:46 UTC
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
Comment 42 Andras Timar 2015-02-01 22:36:31 UTC
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.
Comment 43 Andras Timar 2015-02-01 22:38:52 UTC
CC-ing the expert :)
@Markus, this is what we're talking about. See the unit test.
Comment 44 Matthew Francis 2015-02-16 07:51:13 UTC
*** Bug 81838 has been marked as a duplicate of this bug. ***
Comment 45 Matthew Francis 2015-02-16 08:02:19 UTC
*** Bug 77522 has been marked as a duplicate of this bug. ***
Comment 46 Soufiane 2015-03-24 16:07:58 UTC
Hi, 

Same issue in LO 4.3.6.2 Windows, ubuntu 32 & 64bits !
Any ideas about how to fix will be welcome.

Thanks.
Comment 47 Joel Madero 2015-03-24 16:25:51 UTC
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
Comment 48 Andras Timar 2015-04-13 16:09:22 UTC
*** Bug 87650 has been marked as a duplicate of this bug. ***
Comment 49 Michael Meeks 2015-04-25 10:41:37 UTC
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 =)
Comment 50 reporter_of_bugs 2015-04-26 23:13:26 UTC
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
Comment 51 reporter_of_bugs 2015-04-26 23:25:33 UTC
(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
Comment 52 Buovjaga 2015-04-27 11:11:41 UTC
(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
Comment 53 reporter_of_bugs 2015-04-27 22:02:56 UTC
(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.
Comment 54 Commit Notification 2015-05-28 05:00:10 UTC
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.
Comment 55 Commit Notification 2015-05-28 07:09:09 UTC
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.
Comment 56 Cor Nouws 2015-05-28 07:24:52 UTC
@henri: thanks a lot!
Comment 57 vlb 2015-05-29 17:59:03 UTC
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?
Comment 58 Andras Timar 2015-05-31 19:40:00 UTC
Henry Castro fixed it.
Comment 59 vlb 2015-05-31 21:11:37 UTC
(In reply to Andras Timar from comment #58)
> Henry Castro fixed it.

Is It alzo fixed in LO4.4.4.0?
Comment 60 Joel Madero 2015-05-31 21:46:38 UTC
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!
Comment 61 Denis RADWAN 2015-06-02 08:35:20 UTC
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.
Comment 62 tommy27 2015-06-02 08:40:34 UTC
@Denis
this is not the correct procedure
I revert status to FIXED
Comment 63 Denis RADWAN 2015-06-02 11:24:52 UTC
@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)
Comment 64 Buovjaga 2015-06-02 11:25:54 UTC
(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 :)
Comment 65 Denis RADWAN 2015-06-02 13:22:44 UTC
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
Comment 66 tommy27 2015-06-06 05:42:49 UTC
(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
Comment 67 Cor Nouws 2015-06-10 12:39:05 UTC
*** Bug 91979 has been marked as a duplicate of this bug. ***
Comment 68 Andras Timar 2015-06-14 20:36:52 UTC
(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
Comment 69 Commit Notification 2015-06-16 14:37:33 UTC
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.
Comment 70 Michael Stahl (CIB) 2015-09-15 14:57:53 UTC
removing "backportrequest", was already done
Comment 71 Robinson Tryon (qubit) 2015-12-17 07:22:33 UTC Comment hidden (obsolete)
Comment 72 zian rizky 2018-11-25 07:44:04 UTC Comment hidden (spam)