Description: When you attempt to move an image (png/jpg) in LO 4.4.0.1 rc1, the image is moved as if you are holding down shift. It tries to lock onto the original image location's horizontal/vertical/diagonal axes. Holding down shift while moving the image returns the original expected behavior. This affects moving images in Draw, Impress, and Calc, but not Writer. I guess I'll choose Draw as the component. Steps to reproduce: 1. Create new Drawing 2. Insert an image (jpg or png) 3. Attempt to move the image towards a corner. Expected: The image's movement should be fully within your control. You should have fine-grained control over where to place the image. Actual: The image jerks back to be aligned with the original location's axes. It behaves exactly like you are holding down the shift key to constrain movement. You can even hold down shift to return to the normal movement behavior. My guess is that this change was not intentional and was made as part of 4.4.0's move to constrain image's aspect ratio by default. But movement should not be constrained by default. This one is quite annoying. I bibisected: e1690f3a96306b42e829d63cb23a48e4b90603b5 is the first bad commit commit e1690f3a96306b42e829d63cb23a48e4b90603b5 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Nov 6 01:25:45 2014 +0000 source-hash-3d394257945f6b0a4bc4b5ea397a3942a59c5d06 commit 3d394257945f6b0a4bc4b5ea397a3942a59c5d06 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Thu Sep 25 10:10:54 2014 +0200 Commit: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> CommitDate: Fri Sep 26 23:17:21 2014 +0200 android: Log number of invalidated tiles Change-Id: I1ebfcf48f1d9a44836b4d9bf90c04c3be27cb365 :100644 100644 f732d2eca5665c04418c5202f52de2023fd57ebb dc532e748e279272838eca0b85fcfc70455b79d9 M autogen.log :100644 100644 4aa0bbbc4d0c774f4540a775697688e300221958 320fc8a1e1cea723c36ab1584fde2cd83e6ec887 M ccache.log :100644 100644 eb9fe578cb7122fd159102ff28562fa5172a8697 eec7e583d21818df091b987fb033cc9668d694f4 M commitmsg :100644 100644 d088117fd69635a1cce0ea96c7e423e7a425a553 722be06e15e56cfa7dea23cc01a467a80edb31a6 M make.log :040000 040000 7ea7c51713887b7f29718f7de9355a280eaa686d e19e03ba20bbe96f74780fbeee1859ae684ed0b9 M opt $ git bisect log git bisect start 'latest' 'oldest' # good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # good: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd git bisect good 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5 # bad: [a42da134cd542144fca7ba14cce86c2b409fc18a] source-hash-beadebc0f7eb5582fcb8dcb082d19afdf2751876 git bisect bad a42da134cd542144fca7ba14cce86c2b409fc18a # bad: [5f697ca821720f76105e5539f0408e68a0647481] source-hash-f9695150942341a755a43996d4639eb623d7640b git bisect bad 5f697ca821720f76105e5539f0408e68a0647481 # bad: [3b00b662438462a4b73b0531ffa6192fc7e72638] source-hash-0a5cd87e591d7f87bfab92716079af719259f143 git bisect bad 3b00b662438462a4b73b0531ffa6192fc7e72638 # good: [b4320c4383b3d61076ac1794797bd3162612889d] source-hash-da21f7da44dc577a08ea3bc210083dc8decf18bc git bisect good b4320c4383b3d61076ac1794797bd3162612889d # bad: [e1690f3a96306b42e829d63cb23a48e4b90603b5] source-hash-3d394257945f6b0a4bc4b5ea397a3942a59c5d06 git bisect bad e1690f3a96306b42e829d63cb23a48e4b90603b5 # good: [5de848a6e0a36f6ba90e6c32fd126942fde3293c] source-hash-fd0a49bdd7cf7979d18feff003d1b5fbe53fdc14 git bisect good 5de848a6e0a36f6ba90e6c32fd126942fde3293c # first bad commit: [e1690f3a96306b42e829d63cb23a48e4b90603b5] source-hash-3d394257945f6b0a4bc4b5ea397a3942a59c5d06
OSX 10.10.1 LO 4.4.0.2 WORKSFORME. Can you please rety? Which OS are you on?
I tested this using 4.4.0.1 and 4.4.0.2 using 32bit Fedora 17, 64bit Fedora 20, and 64bit Arch Linux. Fedora 20 is where my bibisect environment is. The Arch machine is the only machine I have access to right now, and that version is: Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: en_US I can confirm that it does affect still affect this Arch version. So this might be Linux specific. I'll try to test on a MS Windows machine when I get a chance.
I just tested this in 64bit MS Windows Vista (yuck), and I can confirm this bug affects LO there too, using: Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: en_US Maybe my steps to reproduce weren't clear enough. I'm inserting a jpg/png, clicking down on it, and immediately dragging it. This will cause the image to turn translucent while I'm dragging it around my screen. At that point, I move it in at least two axes and wiggle it around. It will stick to being lined up with the original image horizontally, vertically, or diagonally. Just as if you were holding down shift in versions <=4.3.x. Try holding shift to see if the behavior changes. Or maybe it doesn't affect OSX 10.10.1.
I added a "see also" to the bug 83808 that caused this behavior, and added my comment. As I suspected, that was the enhancement that attempted to enable porportional image scaling by default for Calc, Impress, and Draw. It also enabled porportional image movement as well. Here is the Draw related commit, mentioned in that report: http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef58e10844dff60cd218306b059ec81d8421f961 In the function "FuDraw::MouseMove" in source file /sd/source/ui/func/fudraw.cxx (the main function changed in the commit), the behavior can be fixed by changing the line: if(bIsImageSelected || (bRestricted && doConstructOrthogonal())) to if(bRestricted && (bIsImageSelected || doConstructOrthogonal())) This change fixes Draw and Impress. I'm guessing there is a similar change that needs to take place for the Calc commit, but that code doesn't seem as obvious to me.
I submitted the patch mentioned above for review: https://gerrit.libreoffice.org/#/c/13900/ Note that this only applies to Draw and Impress. There will need to be another fix made in Calc.
Trent MacAlpine committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6a1a8e6f8d97d24b4063909ef22824875326e28 fdo#88339 Fixed Draw/Impress constrained image movement It will be available in 4.5.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.
I've submitted another patch that should take care of this behavior in Calc. https://gerrit.libreoffice.org/#/c/13975/ At this point, I'm pretty sure this bug is valid, so I'll change the status from NEEDINFO back to NEW until the patch is accepted.
Trent MacAlpine committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4ce891c59a9ab47cfde5fedb89b7d4b19002fae8&h=libreoffice-4-4 fdo#88339 Fixed Draw/Impress constrained image movement It will be available in 4.4.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.
Trent MacAlpine committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a4a68e2515fa54e041004cf63042c1ead00d576 fdo#88339 Fixed Calc constrained image movement It will be available in 4.5.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.
(In reply to Commit Notification from comment #8) > fdo#88339 Fixed Draw/Impress constrained image movement > > It will be available in 4.4.1. Great :) Thanks!
The Calc related patch was merged to master this morning, so I just submitted its twin to 4.4 for review. Hopefully we'll see that one in 4.4.1 too. Though I'm still waiting on that last patch to be reviewed for 4.4, master is already fixed. So I'll be impatient and mark as resolved fixed! :)
Trent MacAlpine committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fdff4b60b6d4beabadab15a4fceb60cb84e542d8&h=libreoffice-4-4 fdo#88339 Fixed Calc constrained image movement It will be available in 4.4.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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef9d28a3605b7e3e1e68212cc44f7379fd2f464a it's unnecessary to obtain the marked object in move mode, fdo#88339 followup It will be available in 4.5.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.
Trent MacAlpine committed a patch related to this issue. It has been pushed to "libreoffice-4-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5417429d0ef2d968b227dd2a533c1bf9cb0156b9&h=libreoffice-4-4-0 fdo#88339 Fixed Calc constrained image movement It will be available in 4.4.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.
*** Bug 88684 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]