Hi Lionel,

I don´t understand the intention of this bugreport. Do you expect a confirmation?

(In reply to comment #1)
> I don´t understand the intention of this bugreport. Do you expect a
> confirmation?

The intention is that the bug eventually gets fixed. Not clear by whom yet.

It would be useful to see whether other people can reproduce on same OS (GNU/Linux) and/or other OSes (MS Windows, MacOS X), to see if the problem is in platform-specific or platform-generic code.

I have tested the following:
Open a report for editing. Mark a control with the mouse. move the control with the mouse from "Detail" to "Group" and back. The cursor look like a hand. It is positioned in the middle of the control.
My System: OpenSuSE 11.4, 
teted with 
LO-Dev Version 3.6.3.0+ (Build ID: 0c3fcef)
LO Version 3.6.1.1 (Build ID: 4db6344)
LO 3.3.4

When I have seen the videos at https://bugs.freedesktop.org/show_bug.cgi?id=44721 I don't understand what you mean. There isn't moved a control with the mouse. The mouse is used for changing the width or hight of a control. Could be you mean the cursor "hand", which suddenly appears while changing the width? Haven't seen such a behaviour before.

@Lionel
I also don´t understand what you want to say respectively I´m not able to reproduce the single steps respectively the wrong behavior.

Now I have had the same behaviour. I wanted to push a rectangle from the footer of a group to detail. When moving the rectangle the lines, which show this moving, suddenly jump about 1,5 cm above the mouse-cursor. I wanted to insert the rectangle at the position which is shown by the lines - but it has been inserted at the position of the mouse (again in the footer, not in the detail-section).

I set the status to New.

Another hint:
Same Database-Document - in one report I can reproduce this behaviour in a different way (pasted at the position of the mouse - shown at another position by the lines), in another report I can't reproduce the behaviour (report, which is edited, when choosen "English" as GUI-Language ...).

(In reply to comment #6)
> <snip> I can reproduce this behaviour 

Hi Robert,

Lionel needs the specification of OS you used (to clarify which OS is affected).

Changed status to "NEEDINFO" (please change again to "NEW" after reply).

@Jochen,

see comment 3. I have tested it with OpenSuSE 11.4 32-bit (linux rpm) and three different versions of LO. Behaviour is all the same.

(In reply to comment #8)
> I have tested it with OpenSuSE 11.4 32-bit (linux rpm)

Can you also test with a windows-OS?

@Lionel:
A Bug reported for a 3.6 Version can not be a 3.5 MAB "by definition", so I remove this one from that Tracking bug. Please feel free to add it to an other MAB tracking bug due to <http://wiki.documentfoundation.org/Most_Annoying_Bugs>

Moving this to 3.6 MAB since we are closing 3.5 MAB meta tracker.

Personally I think that this is just a minor inconvenience and shouldn't be on MAB. Also a test document with clear steps might help as I'm not seeing the issue (on just a blank database form) but more likely than not I just am just missing a step somewhere.



Marking as NORMAL as there is no data loss or anything, just a bit off

Also, how can it block 52471 if that one is fixed?

(In reply to comment #11)

> Personally I think that this is just a minor inconvenience and shouldn't be
> on MAB.

I found it makes designing reports quite cumbersome. It is like a gun that shoots 2m above the crosshairs. It makes it rather difficult to aim.

> Also a test document with clear steps might help as I'm not seeing
> the issue (on just a blank database form) but more likely than not I just am
> just missing a step somewhere.

The problem is in *reports* (done with report builder, not report design), not in forms.

It is one of these problems "sometimes I have it, sometimes not, I don't understand under which conditions I have it". It has been some time since I worked with reports and thus was in position to encounter this bug, but back in December it made me abandon the mouse and enter X/Y coordinates in the properties instead. I'll try to re-reproduce it in the next weeks.

(In reply to comment #12)
> Also, how can it block 52471 if that one is fixed?

Bug 52471 is not fixed, it is marked as a duplicate (I'm not sure that is actually correct, but that is another issue).

I'm also not sure the "blocks" relationship is correct anyway. Maybe it should rather be in "see also".

@Lionel
do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0)

(In reply to comment #15)

> do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0)

Yes, I still reproduce with my 4.2.0.alpha development build.

Ok. let's move it to the mab4.0 list.

(This is an automated message.)

Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.

Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version

is this bug still valid in current 4.2.4.2 release?
if yes, please move it from mab4.1 to mab 4.2 list since 4.1.x is EOL

I still see it in master and 4.2 on OSX, moving to mab4.2

Can someone who had confirmed this bug bibisect it?

Here's a good way to recreate the issue and a workaround.  The issue occurs when sections of the report have a minimum height.

Create a report with a few groups with group headings then, in design mode, use the 'Shrink' control to make the group headings and sections as small as possible then attempt to move an object on the screen, the mouse pointer will be significantly offset from the object as you move it and it will jump from section to section due to the misalignment.  This should recreate the issue easily.

A temporary workaround for folks encountering this issue is to just open the report sections up some and shrink them when you're done.

It would help if you attached a document that gets us as far as possible along the reproducible steps. I suppose at least getting us through: "Create a report with a few groups with group headings then"

please retest with recent 4.3.x or 4.4.x versions.
if issue persists, please move it to mab4.3 list since 4.2.x is EOL

TESTING with LO 4.3.5.1 + LO 4.4.0.0.beta2 on Ubuntu 14.04

- Using attachment 64781 [details] (from the parent bug report). (If it opens as read-only, make sure to right-click and select 'Edit')

I tried to reproduce these results, but the instructions aren't entirely clear. 

(In reply to Steven M Campbell from comment #23)
> Here's a good way to recreate the issue and a workaround.  The issue occurs
> when sections of the report have a minimum height.
> 
> Create a report with a few groups with group headings

Trying to add group elements to the existing report in the test ODB failed, as they would disappear after walking through the mini-wizard to create one.

(In reply to Lionel Elie Mamane from comment #16)
> > do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0)
> 
> Yes, I still reproduce with my 4.2.0.alpha development build.

Lionel/Alex: We're nearly done porting mab4.2 -> mab4.3. Can one of you confirm that this bug is still present in 4.3, 4.4, or 4.5 so we can bump it forward?

Thanks!

Created attachment 110876 [details]
Describes the difference between moved control and mouse-position.

Created attachment 110877 [details]
Database with report for testing.

Open the report for editing.
Mark one filed of the report with the mouse.
Try to move the field with the mouse.
The position of the mouse is under the control.
It isn't as much as Lionel described and I could confirm with one report - don't know which. But the behavior is the same in old LO-versions and in LO 4.3.5.2, also the newer LO 4.4 and LO 4.5-Dev.
Tested with OpenSUSE 12.3 64bit rpm Linux.

Created attachment 110903 [details]
bug demonstration video

Yes, reproduced in 4.3.3.2 (Debian build). Here's a screencast (video) to show the problem. You clearly see that although the mouse is moved only horizontally (from left to right), the moved control "jumps" up by 0.75cm vertically.

(In reply to Lionel Elie Mamane from comment #30)
> ... the moved control "jumps" up by 0.75cm
> vertically.

at least is improved from the 1.25 cm of the initial report :-)

I can reproduce this in LO 3.3.0, so it doesn't appear to be a regression but an inherited bug.

-> Removing Whiteboard: bibisectRequest and Keywords: regression
-> Setting Version to "Inherited from OOo"

Adding self to CC if not already on