Bug 54933 - EDITING Report builder: mouse-move control: gap between mouse position
Summary: EDITING Report builder: mouse-move control: gap between mouse position
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Database (show other bugs)
Version: Inherited From OOo
Hardware: All All
: highest normal
Assignee: Not Assigned
QA Contact: Joel Madero
URL:
Whiteboard:
Keywords:
Depends on: 44721
Blocks: 54930 mab4.3 52471
  Show dependency treegraph
 
Reported: 2012-09-14 15:45 UTC by Lionel Elie Mamane
Modified: 2015-01-03 17:39 UTC (History)
11 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Describes the difference between moved control and mouse-position. (61.20 KB, application/pdf)
2014-12-15 16:41 UTC, robert
Details
Database with report for testing. (8.35 KB, application/vnd.oasis.opendocument.database)
2014-12-15 16:53 UTC, robert
Details
bug demonstration video (386.24 KB, video/ogg)
2014-12-16 11:45 UTC, Lionel Elie Mamane
Details

Description Lionel Elie Mamane 2012-09-14 15:45:40 UTC
+++ This bug was initially created as a clone of Bug #44721 +++

When moving a control with the mouse (drag'n drop), the control is actually about 1.25cm *above* the mouse pointer. The control starts at the mouse pointer, but then "jumps up".
Comment 1 Jochen 2012-09-15 16:07:12 UTC
Hi Lionel,

I don´t understand the intention of this bugreport. Do you expect a confirmation?
Comment 2 Lionel Elie Mamane 2012-09-15 20:34:00 UTC
(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.
Comment 3 robert 2012-09-16 08:05:00 UTC
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.
Comment 4 Jochen 2012-09-16 08:09:59 UTC
@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.
Comment 5 robert 2012-09-16 10:02:47 UTC
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.
Comment 6 robert 2012-09-16 10:11:29 UTC
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 ...).
Comment 7 Jochen 2012-09-16 10:17:46 UTC
(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).
Comment 8 robert 2012-09-16 18:43:42 UTC
@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.
Comment 9 Jochen 2012-09-16 18:48:56 UTC
(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?
Comment 10 Rainer Bielefeld Retired 2012-10-05 06:49:55 UTC
@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>
Comment 11 Joel Madero 2013-02-12 19:31:36 UTC
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
Comment 12 Joel Madero 2013-02-12 19:31:56 UTC
Also, how can it block 52471 if that one is fixed?
Comment 13 Lionel Elie Mamane 2013-02-12 20:17:39 UTC
(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.
Comment 14 Lionel Elie Mamane 2013-02-12 20:21:06 UTC
(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".
Comment 15 tommy27 2013-08-10 12:25:42 UTC
@Lionel
do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0)
Comment 16 Lionel Elie Mamane 2013-08-10 17:53:06 UTC
(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.
Comment 17 tommy27 2013-08-10 18:52:53 UTC
Ok. let's move it to the mab4.0 list.
Comment 18 Björn Michaelsen 2014-01-17 09:58:49 UTC
(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.
Comment 19 chtfn 2014-02-12 08:23:09 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 20 tommy27 2014-05-13 04:42:46 UTC
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
Comment 21 Alex Thurgood 2014-05-25 09:50:50 UTC
I still see it in master and 4.2 on OSX, moving to mab4.2
Comment 22 Joel Madero 2014-06-09 16:29:33 UTC
Can someone who had confirmed this bug bibisect it?
Comment 23 Steven M Campbell 2014-07-09 13:43:48 UTC
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.
Comment 24 Joel Madero 2014-07-09 15:09:24 UTC
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"
Comment 25 tommy27 2014-12-08 09:00:09 UTC
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
Comment 26 Robinson Tryon (qubit) 2014-12-08 13:15:46 UTC
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.
Comment 27 Robinson Tryon (qubit) 2014-12-14 03:58:03 UTC
(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!
Comment 28 robert 2014-12-15 16:41:34 UTC
Created attachment 110876 [details]
Describes the difference between moved control and mouse-position.
Comment 29 robert 2014-12-15 16:53:26 UTC
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.
Comment 30 Lionel Elie Mamane 2014-12-16 11:45:54 UTC
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.
Comment 31 tommy27 2014-12-16 12:04:33 UTC
(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 :-)
Comment 32 Matthew Francis 2014-12-21 13:43:21 UTC
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"
Comment 33 Alex Thurgood 2015-01-03 17:39:48 UTC
Adding self to CC if not already on


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.