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: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 118905 (view as bug list)
Depends on: 44721
Blocks: 54930 52471
  Show dependency treegraph
 
Reported: 2012-09-14 15:45 UTC by Lionel Elie Mamane
Modified: 2022-07-01 03:34 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


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

Note You need to log in before you can comment on or make changes to this bug.
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 Großkopf 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 Großkopf 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 Großkopf 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 Großkopf 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 Comment hidden (obsolete)
Comment 19 Stéphane Guillou (stragu) 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 Großkopf 2014-12-15 16:41:34 UTC
Created attachment 110876 [details]
Describes the difference between moved control and mouse-position.
Comment 29 Robert Großkopf 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 Comment hidden (no-value)
Comment 34 Julien Nabet 2015-03-10 22:06:22 UTC
Just for the record, on pc Debian x86-64 with master sources updated 2 days ago, I can reproduce this.

I wonder who could give some code pointers so someone may start to dig into this one.
Comment 35 Roberto 2016-01-21 05:05:16 UTC
Just informing that I accidentally changed the importance to 'enhancement' for a while (I am really sorry, I didn't realize that I was editing the wrong bug). I don't remember the original status, so I'm changing it back to 'normal', just like Joel Madero did, according to Comment 11.

Finally, I sincerely offer you my apologies for the troubles this mistake might cause to you.
Comment 36 Alfons Kuchlbacher 2016-02-28 08:43:21 UTC
same behaviour here, my system: LO 5.1, Debian testing amd64, LO is from homepage, not from repos. i have this behaviour since i use LO (about since version 3). its a nuisance, when editing reports to make them look better. resizing with mouse works properly, also resizing and positioning with the context-menu manually by editing x or y values in numbers works properly, only when drag'n'drop per mouse, the object jumps when selcted.
Comment 37 QA Administrators 2017-03-06 16:15:42 UTC Comment hidden (obsolete)
Comment 38 Robert Großkopf 2017-03-08 19:43:18 UTC
Bug still exists with LO 5.3.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux.

The difference between moved control and mouse-position disappears when deleting sorting and grouping. When I tried to change the height of the group of 
https://bugs.documentfoundation.org/attachment.cgi?id=110876
I got a part of the group without background. After saving the report and reopening, the background of the group appears and the buggy behavior with mouse-position and control-position has gone.
Comment 39 QA Administrators 2018-03-09 03:45:56 UTC Comment hidden (obsolete)
Comment 40 Robert Großkopf 2018-07-30 14:02:57 UTC
*** Bug 118905 has been marked as a duplicate of this bug. ***
Comment 41 Xisco Faulí 2019-01-11 20:39:15 UTC
Lowering importance: Highest + Inherit from OOo doesn't make much sense at this point anymore...
Comment 42 Robert Großkopf 2019-01-12 07:06:41 UTC
(In reply to Xisco Faulí from comment #41)
> Lowering importance: Highest + Inherit from OOo doesn't make much sense at
> this point anymore...

Why doesn't it make much sense anymore? Does anybody want to remove from LO? Report Builder is used with every database-engine connected to Base.
Comment 43 milly texas 2020-06-30 03:00:09 UTC Comment hidden (spam)
Comment 44 QA Administrators 2022-07-01 03:34:20 UTC
Dear Lionel Elie Mamane,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug