Bug 50725 - UI: Click on frame border makes it move (without drag)
Summary: UI: Click on frame border makes it move (without drag)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: All All
: medium normal
Assignee: Sarper Akdemir (allotropia)
URL:
Whiteboard: target:24.2.0 target:7.6.0.2
Keywords:
Depends on:
Blocks: Frame
  Show dependency treegraph
 
Reported: 2012-06-05 06:27 UTC by fabien.michel
Modified: 2023-07-24 18:44 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Video show bug (549.91 KB, video/mp4)
2012-06-05 06:27 UTC, fabien.michel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fabien.michel 2012-06-05 06:27:25 UTC
Created attachment 62585 [details]
Video show bug

Click on the border of a text frame. When the button is released, quickly move the mouse somewhere on the page.
The frame follows the mouse and positions itself elsewhere. The expected behavior is that the frame stay in place.

(cf attached video)
Comment 1 Roman Eisele 2012-06-17 01:48:17 UTC
@Fabien Michel:
Thank you very much for your report, especially for the attached videw, which is very impressive indeed!

However, I can NOT reproduce the problem with LibreOffice 3.5.4.2 (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18), German langpack installed, on MacOS X 10.6.8 German UI. If I try to repeat exactly what the screencast shows, everything works for me as expected -- no moving frame, the frame stays in place.

So we need to find out what makes the difference, i.e. why you see this problem and I don't see it. Therefore, I want to ask you:

1) Which version of MacOS X do you use (10.5.x, 10.6.x, 10.7.x)?

2) Do you have any kind of accessability utility enabled? I mean, in the MacOS System Preferences, in the section "Accès universel" (to quote the Frech titles, because Apple names this section very differently ;-), do you have checked any options, e.g. "Activer l’accès pour les périphériques d’aide"? Or do you have any other special system utilities installed?
   I ask this (no. 2) because the use of accessability utilities is know to cause many strange issues; the problem you observed could be one of these issues.

3) And I ask this also because the screencast shows very nice effects which emphasize the mouse pointer (cursor) by a yellow circle and emphasize every mouse click by a blue circle. Are these effects part of the screencast software, or are they added by some system utility you have installed?
   (Forgive me if no. 3 is a stupid question, but I just don't happen to know this ;-) And any special utility you may have installed could have an influence on the problem you observe.

Thank you very much for your answers in advance!
Comment 2 fabien.michel 2012-06-18 00:17:10 UTC
Sorry for the lack of information.


1) I use MacOS 10.7.3 on a white macbook (2008) and LibreOffice 3.5.4.2 
Build ID: 165a79a-7059095-e13bb37-fef39a4-9503d18
But i've also reproduce on a 10.6.x (macbook pro) With Libreoffice 3.5.3.x

2) I've try with and without accessibility option you describe. And it does not change anything.

3) I use http://www.screencast-o-matic.com/ to capture screen animation. It automatically add clicking and moving effects on the mouse.
Of course the problem occur without this utility.
Comment 3 Roman Eisele 2012-06-18 11:13:31 UTC
(In reply to comment #2)
> Sorry for the lack of information.

On the contrary, thank you very much for your additonal information and testing! It helps us to make sure that the issue is not related to some special circumstances (e.g., on MacOS X, accessibility options can cause really strange things in LibreOffice ...).

And the one who has to say "sorry" is me ;-) After reading your answers, which made clear to me that there no special circumstances which could explain this issue, I tried again to reproduce your observation. And this time, it worked -- therefore:

(Most times) REPRODUCIBLE with LibreOffice 3.5.4.2 (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18), German langpack installed, on MacOS X 10.6.8 German UI.

Two observations:
* for me, the frame just does not move always, but often;
* I have to move the mouse really *very* quickly after I release the button to make the frame move.

These two points may explain why I could not reproduce the problem when I tried first (comment #1) -- sorry again for that! -- I did not try hard enough and moved the mouse not quickly enough.

Set Status to NEW because bug is reproducible.
Set Version picker to "3.5.3 release" according to comment #2.
Comment 4 Roman Eisele 2012-06-18 11:18:10 UTC
Also

* REPRODUCIBLE with LibreOffice 3.4.4, German langpack installed, on MacOS X
10.6.8 German UI.

Therefore changed Version picker to "3.4.4 release" (the Version field should always contain the FIRST version in which a bug can be reproduced).

* REPRODUCIBLE with LibreOffice 3.6.0beta1 (Build ID: 1f1cdd8), German langpack installed, on MacOS X 10.6.8 German UI. So the bug is still present in the 3.6 branch.


Can someone please test if this bug is reproducible on Windows/Linux? You may need to try more than once, of course (see my comment #3) ... Thanks!
Comment 5 Roman Eisele 2012-06-18 23:15:55 UTC
(In reply to comment #4)
> Can someone please test if this bug is reproducible on Windows/Linux?
I did it myself for WinXP:

REPRODUCIBLE with LibreOffice 3.5.4.2, German UI, on WinXP German UI.
A real cross-platform bug.

-> Changed Platform settings accordingly.


@Thorsten Behrens,
@Radek Doulik:
Could you please take a look at this issue? It is not terrible, it is not very urgent, but it is still annoying and rather irritating. For example, if someone repeats this unintentionally two or three times, and each time moves a frame for some px, he/she will break the slide layout step by step and notice this only when it is too late, i.e. when Undo will not work anymore.

Thank you very much in advance!
Comment 6 fabien.michel 2012-11-15 11:56:58 UTC
Always occurs with Version 3.6.3.2 (Build ID: 58f22d5) On Mac OS X Lion 10.7.5
Comment 7 QA Administrators 2015-01-05 17:51:39 UTC Comment hidden (obsolete)
Comment 8 Buovjaga 2015-01-22 17:14:24 UTC
I can't reproduce this even if I try to move the mouse away as fast as humanely possible.

Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+
Build ID: 07e84cae983c08afdba03018413a19d01abb3006
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-19_06:15:38
Comment 9 QA Administrators 2016-02-21 08:35:51 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2017-03-06 15:22:38 UTC Comment hidden (obsolete)
Comment 11 fabien.michel 2017-03-06 16:06:44 UTC
Still occure with Version: 5.3.0.3 (Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1)
On a recent MacBook Pro (2013, Core i5, SSD, 8Go RAM) on macOS El Capitan (10.11)
Comment 12 QA Administrators 2018-06-27 02:47:48 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2020-06-27 03:49:05 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2022-06-28 03:25:43 UTC Comment hidden (obsolete)
Comment 15 Armin Le Grand (allotropia) 2023-05-22 12:59:09 UTC
Took a look.

Checked if I can simply reproduce, but not so simple - maybe my machine is too fast (?) That task is older and it would be interesting to hear on which system (regarding performance) this happens.

@fabien.michel@hespul.org: Could you please add infos about system?

Still - could *sometimes* get a move, but MouseUp & Move were so close together, I am not sure if that was indeed the error. What I tried is: Move mouse in a smooth regular  movement to the right over the border, then - without changing movement - press & release left Mouse Button.

Next I tried with & without snap-to-grid, no real change. Next I changed tools/options/impress/grid to much higher resolution -> THAT makes it immediately reproducible (!)

Seems to have to do with minimal move/snap, will check code now. Note: Hard to debug, as always with interactions...
Comment 16 fabien.michel 2023-05-22 13:46:47 UTC
I'm now on a Linux based OS. Therefore the machine I'm working on is powerful. I can't reproduce the problem.
Comment 17 Armin Le Grand (allotropia) 2023-05-22 14:39:12 UTC
Indeed hard to debug. Not sure if that change of GridSnap is involved. I made sure that there is *no* direct call of SdrDragView::EndDragObj after SdrDragView::BegDragObj (so *without* SdrDragView::MovDragObj) except ckick without moving the mouse.

Saw that at SdrDragView::BegDragObj param nMinMov (that defines on how many pixels it's a 'move' at all) gets set by FuSelection::MouseButtonDown where it gets calculated as

    sal_uInt16 nDrgLog = sal_uInt16 ( mpWindow->PixelToLogic(Size(DRGPIX,0)).Width() );

where DRGPIX is defined as

const int DRGPIX     = 2;    // Drag MinMove in Pixel

in sd/source/ui/animations/motionpathtag.cxx. Unfortunately not in configuration, but at just two pixels - and then snapping to position(s) if activated - that might already explain the 'effect'. It would be nice if the people seeing this problem could try with e.g.

DRGPIX = 5 or 10

if it still happens. Two pixels might be too low for people with slow click or sensible optical mice or might even have to do with the nowadays usually highly increased ScreenResolution...

If that is the case we should make that value configurable & evtl. 'scale' from a default value of '2' for 640x480 to the real screen resolution.

Just my 2ct
Comment 18 Sarper Akdemir (allotropia) 2023-07-11 13:28:48 UTC Comment hidden (obsolete)
Comment 19 Commit Notification 2023-07-21 12:32:34 UTC
Sarper Akdemir committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/83f7c6fe5bb233fa9827ff968710822b95562075

tdf#50725: sd: add new configuration option DragThresholdPixels

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2023-07-23 13:20:32 UTC
Sarper Akdemir committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/4c0cda6831d2c401642d6b42c1f596cb68a1cece

tdf#50725: sd: add new configuration option DragThresholdPixels

It will be available in 7.6.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Sarper Akdemir (allotropia) 2023-07-24 18:44:10 UTC
I have implemented Armin's suggestions as a fix for this one, hopefully this resolves problems mentioned. (i.e. bumping up the drag pixel threshold to 6 pixels & making it configurable)