Description: After selecting a frame to move it, dragging on any object contained within the frame causes the frame to lose focus and only move the object clicked on instead. I can confirm this broken behavior under win32 4.1.0.4, rhel 64 bit 4.1.0.4, rhel 64 bit 4.1.1.2, arch 32 bit 4.1.1.2 It was working properly in 4.0.2.2. Steps to reproduce 1. Create a frame. 2. Insert an image into frame. 3. Click outer frame to give the frame focus. 4. Move the frame by dragging, starting drag over the contained picture. Current behavior The frame loses focus and only the image is moved. Expected behavior The whole frame should remain selected and move. After clicking on the frame border, the frame has has focus. Dragging ANYWHERE inside the frame borders should move the frame, whether the cursor is over an object or not.
Hi tmacalp, thanks for the issue. Can you pls attach a sample file showing the issue? Best, Cor
Created attachment 85586 [details] Example document of frame contents moving instead of frames I've attached a document that should illustrate the problem.
@tmacalp thank for the very nice and clear test file. bug confirmed in 4.1.0 and 4.1.1 final releases under Win7 64bit. it works in 4.0.5 final, hence regression. adding Writer expert to CC-list.
change caused by: commit e80a8b6f14fac6bb6cc7ea55b118f95472d5b654 Author: Lennard Wasserthal <Wasserthal@nefkom.net> AuthorDate: Sat Feb 9 14:31:21 2013 +0100 fdo#55430 switches off text mode when clicking an other object. This patch complements 85ea03ae536831649b104694d08dced4d4c8663f (and 6fbba11da54b52554941f00b07e42cc5d7a1643c, which didn't work correctly before) This also fixes issues when clicking on another object to stop text editing. Switches off text mode, and instantaneously selects the other object. (Rotation doesn't belong into the ./sd/ text routine AT ALL, which also caused bug 37482, which is resolved differently from now on) (Creating text fields doesn't belong into the ./sc/ shape text routine either, and if this executed, it causes funny glitches) Known issues: text mode stays on when you use drag'n drop (the one WITH waiting, to move to other applications etc). ... so if a click doesn't select an object inside another marked object it's a bug, but if a click drags the object inside marked object it's also a bug?
(In reply to comment #4) > ... so if a click doesn't select an object inside another marked object > it's a bug, but if a click drags the object inside marked object it's also a > bug? for the latter the work around is dragging on the border of the frame. But still ..
I didn't cause this problem, my patch was before 4.0.2.2. Confirmed with win32 4.1.0.4 Well, Writer has this behavior. Not in excel. Not in impress. And knows what else? If you drag while the outer frame is selected, the inner object is moved erratically, it seems that a CORNER of the inner picture is moved to where the mouse cursor was on button release. Writer seems to select the object in the front, on mouse down. My patch has its effect on mouse up, i.e. later. Note: This strange behavior seems to be some other sort of moving. the mouse cursor has a rectangle attached to it, which is a hind of moving that allows to move the item to other windows. In Impress, it only occcurs after waiting some time.
OOps! I forgot that I added some patches later! Yep, you may be right. Didn't read your post fully, Michael Stahl.
The patch e80a8b6f14fac6bb6cc7ea55b118f95472d5b654 was anyway only supposed to stop text editing. Why is it acting even under these conditions?
Please dont nuke my patch now. It changed different things. Perhaps, I need to add an additional condition to if ( rSh.IsSelFrmMode()) on line 3023 in sw/source/ui/docvw/edtwin.cxx . Such a condition as ( && TextEditMode...) etc...
(In reply to comment #5) > (In reply to comment #4) > > > ... so if a click doesn't select an object inside another marked object > > it's a bug, but if a click drags the object inside marked object it's also a > > bug? > > for the latter the work around is dragging on the border of the frame. But > still .. However, when the user sees that the picture moves, in stead of the frame, it will be natrural behaviour to put the mouse on the frame border... so I consider this not a sever problem... (just IMO of course)
(In reply to comment #10) > > However, when the user sees that the picture moves, in stead of the frame, > it will be natrural behaviour to put the mouse on the frame border... so I > consider this not a sever problem... > (just IMO of course) While this bug might have an easy work around, it's still quite annoying and something I still hope to be fixed. It is also an obvious regression that affects commonly used behavior, which typically warrants an elevated priority. By the way, what is the intended behavior for selecting objects contained in a selected frame in Writer? It appears that bug 55430 implemented the ability to select an object in the foreground of another selected object in Draw. Is the current similar behavior in Writer a side effect of that patch? For instance, If I have a pictures, frames, or draw objects anchored to and within a selected framed, I can now single click these items to select them. This ability came with 4.1.0. I will say that this is functionality I've been wanting for a while, especially for working with large full-page frames. Of course, this feature only applies to selecting interior objects (frames, draw objects, pictures). Would a user also expect a single click on a section of text to deselect the frame and take you into text edit mode as well? What about clicking on a table border or blank area within a frame? (In reply to comment #6) > > Note: This strange behavior seems to be some other sort of moving. the mouse > cursor has a rectangle attached to it, which is a hind of moving that allows > to move the item to other windows. In Impress, it only occcurs after waiting > some time. You're right! This observation is quite interesting. The original steps to reproduce immediately move the image with the long-click type move icon/behavior. My guess is the current buggy behavior is from only addressing the a normal move case and the other long-click "move-between-window" move type was not addressed. It's almost as if this unexpected move attempt short-circuits the the standard long-click delay.
OK, this should do it. https://gerrit.libreoffice.org/#/c/8866/ Sadly, I had problems with the build system before.
yep, looks like that fixes it, thanks Lennard!
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b21eea4b737abe9684da937423540963c7265d6 fdo#69157 Apply object-in front selection on mouseUp 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.
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=351ab7b879a1e5bf879600bf47909181029a4d11&h=libreoffice-4-2 fdo#69157 Apply object-in front selection on mouseUp It will be available in LibreOffice 4.2.4. 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.
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c7cec7bb9ea7ef0aaa18a5c39eca13c446f974c5&h=libreoffice-4-1 fdo#69157 Apply object-in front selection on mouseUp It will be available in LibreOffice 4.1.7. 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.
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "libreoffice-4-1-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0fb0d938434477898ee8b54bc7da523d5120ea0&h=libreoffice-4-1-6 fdo#69157 Apply object-in front selection on mouseUp It will be available already in LibreOffice 4.1.6. 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.