Download it now!
Bug 69157 - When moving frame, contents are moved instead of frame
Summary: When moving frame, contents are moved instead of frame
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other All
: medium normal
Assignee: Lennard Wasserthal
URL:
Whiteboard: target:4.3.0 target:4.2.4 target:4.1.6
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-09-10 01:57 UTC by tmacalp
Modified: 2014-04-14 15:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document of frame contents moving instead of frames (30.66 KB, application/vnd.oasis.opendocument.text)
2013-09-10 21:15 UTC, tmacalp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2013-09-10 01:57:34 UTC
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.
Comment 1 Cor Nouws 2013-09-10 06:24:09 UTC
Hi tmacalp,

thanks for the issue. Can you pls attach a sample file showing the issue?
Best,
Cor
Comment 2 tmacalp 2013-09-10 21:15:56 UTC
Created attachment 85586 [details]
Example document of frame contents moving instead of frames

I've attached a document that should illustrate the problem.
Comment 3 tommy27 2013-09-29 07:08:42 UTC
@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.
Comment 4 Michael Stahl (CIB) 2013-12-06 23:15:56 UTC
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?
Comment 5 Cor Nouws 2013-12-07 16:13:11 UTC
(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 ..
Comment 6 Lennard Wasserthal 2013-12-07 17:29:26 UTC
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.
Comment 7 Lennard Wasserthal 2013-12-07 17:31:19 UTC
OOps!

I forgot that I added some patches later!

Yep, you may be right.

Didn't read your post fully, Michael Stahl.
Comment 8 Lennard Wasserthal 2013-12-07 17:38:14 UTC
The patch

e80a8b6f14fac6bb6cc7ea55b118f95472d5b654
 was anyway only supposed to stop text editing. Why is it acting even under these conditions?
Comment 9 Lennard Wasserthal 2013-12-07 17:44:16 UTC
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...
Comment 10 Cor Nouws 2013-12-07 23:29:14 UTC
(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)
Comment 11 tmacalp 2014-04-02 18:28:25 UTC
(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.
Comment 12 Lennard Wasserthal 2014-04-05 09:56:22 UTC
OK, this should do it.

https://gerrit.libreoffice.org/#/c/8866/

Sadly, I had problems with the build system before.
Comment 13 Michael Stahl (CIB) 2014-04-09 12:44:21 UTC
yep, looks like that fixes it, thanks Lennard!
Comment 14 Commit Notification 2014-04-09 12:44:41 UTC
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.
Comment 15 Commit Notification 2014-04-09 12:46:06 UTC
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.
Comment 16 Commit Notification 2014-04-11 12:20:45 UTC
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.
Comment 17 Commit Notification 2014-04-14 15:51:56 UTC
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.