Suppose you have a rectangle. You want to move it. You place mouse cursor over the rectangle and left click it. Wait a moment. The cursor changes and you move the mouse. You do not see object shadow moving. This is the bug. You release mouse button and the rectangle is in the new position. But you were not able to position the rectangle because the object shadow was invisible while dragging. But: move the mouse over the rectangle and left click mouse while moving. Guess what? The object shadow is visible and you can position the object. So this is a difference. The effect is even more visible while option "Snap Lines when Moving" is selected. You can see snap lines vanishing after a part of the second after you left click your mouse while the mouse is not moving. When you start with moving mouse you can see snap lines moving together with the object shadow as it should always be. The effect is most annoying while trying to move lines. Most times you end up with a line moving without shadow. Therefore I assume fixing this bug is kind of important issue.
(In reply to comment #0) > Suppose you have a rectangle. You want to move it. You place mouse cursor over > the rectangle and left click it. Wait a moment. The cursor changes and you move > the mouse. You do not see object shadow moving. This is the bug. You release > mouse button and the rectangle is in the new position. But you were not able to > position the rectangle because the object shadow was invisible while dragging. It works for me: Version 3.6.0.4 (Build ID: 932b512) Slackware Linux 13.37 I can see the shadow while dragging the rectangle. Same happens when dragging a line. Which Operating System are you using? Can you try again with the latest Libreoffice release.
(In reply to comment #1) > (In reply to comment #0) > > Suppose you have a rectangle. You want to move it. You place mouse cursor over > > the rectangle and left click it. Wait a moment. The cursor changes and you move > > the mouse. You do not see object shadow moving. This is the bug. You release > > mouse button and the rectangle is in the new position. But you were not able to > > position the rectangle because the object shadow was invisible while dragging. > > It works for me: > Version 3.6.0.4 (Build ID: 932b512) Slackware Linux 13.37 > I can see the shadow while dragging the rectangle. Same happens when dragging a > line. > I'd like to clarify: I can see the shadow too, but ONLY when I start dragging sufficiently fast after clicking the object. When I click, then wait a second or two, then the shadow vanishes. So: don not click and immediately drag, but click, wait, and drag. You should see the effect. > Which Operating System are you using? It is Win 7 Home Premium or Win 7 Professional. However I've seen this effect under Linux as well. > Can you try again with the latest > Libreoffice release. I can now see this with Draw from LibreOffice Version 3.6.1.2 (Build ID: e29a214).
I can confirm observations in Comment 2. Effect is [Reproducible] with Server Installation of "LibreOffice 3.6.2.1 rc German UI/ German Locale [Build-ID: ba822cc] on German WIN7 Home Premium (64bit), but I wonder whether it's a bug or a feature. When I immediately start to drag the shape I see the "4 compass points" mouse pointer, and a "shadow" of the shape will follow the mouse pointer. When I wait few moments (1 second or so), the control points change their color and become a little darker (now the modus has changed to "move without shadow"), and the mouse pointer will change to the "moving" view when I start dragging the shape, and no "shadow" will follow the mouse pointer. With parallel installation of Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: 24761a6]" {tinderbox: @6, pull time 2012-09-18 23:21:04} on German WIN7 Home Premium (64bit) behavior is similar to 3.6, but here the mouse pointer changes to moving view after few moments even before I start to drag the shape. When You have activated 'Tools -> Options -> DRAW -> View - Snap lines when moving' he snap lines will disappear in the moment where the modus changes to "move without shadow" I thought that there would be a setting "shadow when move", what might be related, but I can't find it. Same with LibO 3.5.1.4, 3.4.5, 3.3.3 and OOo 1.1.5, never worked different. So this seems to be a feature? But I think it would be better if mouse pointer view changes immediately when the behavior changes to "no shadow", as it does in 3.7 and also did in 3.4.5. This problem is already visible with 3.5.1. So this seems to be the remaining bug. @sunmoon51@gazeta.pl What do you think? @Hashem: Can you confirm my observations for Linux?
(In reply to comment #3) > So this seems to be the remaining bug. > > @sunmoon51@gazeta.pl > What do you think? I'm not able to check 3.4.5 or 3.7 so I stay with current version of 3.6. IMO it's a bug not a feature because moving without shadow is (at least for me) unusable. When I move the object I want to precisely locate it and without a shadow it's simply not possible. As far as mouse cursor is concerned, it should always change to 'moving' view while moving. "4 compass points" pointer while moving is not what I'd want. But it's not so important. The most important issue is "need for speed". In order to see the shadow I have to do things fast; it's not what I like...
(In reply to comment #3) > @Hashem: > Can you confirm my observations for Linux? Yes, confirmed the behavior in: Version 3.6.1.2 (Build ID: e29a214) Slackware Linux 13.37. The lag between clicking and dragging shows this bug.
Looking at 3.6.4 the bug is still present. You are slow in fixing the bugs, aren't you?
*** Bug 74289 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
(In reply to Joel Madero from comment #8) Yes, the bug is still present. I can see it now on LibreOffice 4.4.2.2 (Draw). This is on Windows 7 Home Premium 64 bit PL. There are no changes in the bug behavior since it has been reported. After almost three years I can only add I don't use LibreOffice Draw at all just because this nasty bug.
I cannot reproduce the issue. The normal object interaction works as expected meaning most user will never face the problem. After a few seconds without interaction while left mouse button has been pressed the cursor changes from IDC_SIZEALL into the system drag cursor. Moving the mouse now lets the object remain where it is (of course with the shadow) until drop - and the object moves to the target position. WORKSFORME or FIXED? Version: 5.2.0.0.alpha0+ Build ID: 6b232aeecc55f1715bc111e636e36a8e24827efb CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-26_07:40:04 Locale: de-DE (de_DE) BTW: The same test in Writer with an empty document "kills" the dragged object after dropping. Adding text reactives them. And Impress has no issue. Setting component to UI since the question is not limited to just Draw.
I've just installed 5.2.0.0.alpha1. The bug is still present exactly as described in the original post. Simply: draw an object, click on it and wait a second or two, and try to drag it. There is NO object shadow at all; the object is moved, but you can't position it precisely because of lack of object shadow.
Here is a video how it looks on Linux (LibO Fresh, KDE). https://youtu.be/r5c23HX5k6k
Assigning to Susobhan as he is doing sidebar work in context of GSoC (and CC'ing bubli). The long press interaction is very questionable. But changing this behavior could have unexpected side effects. So we have to be careful. My suggestion is to drag objects from the gallery in the same way as it is done in the document. Meaning you don't see a drag cursor but the object as drag image. And with "Snap Lines when moving" (Options > Draw > View) enabled, the boundary would be indicated clearly making the exact placement a piece of cake. Positive by-effect is the visualization of how objects are put from the gallery to the document. It's not 'select, point and click' (like when you add shapes) but 'drag and drop'. And that's very clear when the image is shown. Question to Susobhan: Is it feasible? Too much effort for GSoC? In scope? Question to Submoon: Does this solve your issue?
Actually there is no object as drag image seen while dragging from the gallery. Just drag cursor. And it is clear. IMHO it shouldn't change. But, the proposal in fact doesn't solve the issue. Not only first object placement should be considered but also (and mainly) improvements and modifications of the diagram which require moving objects already present on the drawing. And, I don't see what unexpected side effects could be introduced. Just click the object and don't let object shadow and lines vanish. That's all what is needed.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
After 5 years of hopeless waiting the bug is still present. LibreOffice version is 5.3.3, Windows version is 10 Home 64 bit. Thank you.
Setting Assignee back to default. Please change it back if you're still working on this issue
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
After 6 (SIX!) years of hopeless waiting the bug is still present. LibreOffice version is 6.1.3.2, Windows version is 10 Home 64 bit. Wersja: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb Wątki CPU: 4; OS:Windows 10.0; UI render:domyślny; Ustawienia regionalne: pl-PL (pl_PL); Calc: group threaded I can only add I don't use LibreOffice Draw at all just because this nasty bug. Thank you.
This is not a bug at all. There exists two modes. One is the move mode with the "cross" mouse pointer. You need it, if you want to move an object within the current page. The other one is a drag mode. It has a rectangle as mouse pointer. You need it, if you want to move or copy the object to a different page in the page panel or to a different layer. That mode keeps the position of the object. You use the modifier key Ctrl to switch form move to copy. Copying works too on the same page. In addition you need that mode, if you want to put an object into a Gallery theme or you want to drag it into a different document. For me the time of about a second to switch from move mode to drag mode is just right.
Regina, thank you for the first knowledgeable and competent comment in thread. You are obviously right (although I couldn't find this behaviour documented in manual at all). Nevertheless I still think the period of switching modes is much too short. You say "about a second", but switching is almost instant on my computer, it is 0,2s maybe, just wink. This clearly was a reason of this bug report.
Dear sunmoon51, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear sunmoon51, 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
😥