Problem description: When wanting to resize a text box in Impress, any sane user will click the text box to select it, then go to one of the eight resize handles which appear along the border of the text box. However, even though the mouse cursor changes to the resize icon, clicking on the handle causes the box to be picked up and moved, just as though the user had clicked on the text box frame away from the resize handles. Steps to reproduce: 1. Create a text box in Impress. Type some text. 2. Click off the text box to deselect it. 3. Click the edge of the text box again to select it 4. Attempt to resize the box by clicking on one of its resize handles 5. Watch how the box is picked up and moved instead. 6. Swear. Current behavior: Text box gets moved rather than resized. Expected behavior: Text box should be resized rather than moved. Operating System: Ubuntu Version: 4.1.4.2 release
Hello Michael, Sorry, I'm not able to reproduce this problem. All I get on a second click, is that the selection handles change from blue to red (=rotation handles) On a mouse down, the handles nor the frame shows any change (LibreOffice 4.1.4 and 4.2.0 on Ubuntu) Regards, Cor
Are you clicking to deselect the box first? If I go back and select a text box again, I get a blinking edit text cursor after the text and the frame and resize handles light up. If I try to click-and-drag on the resize handles, the box ends up moving. It seems to be related to how long you depress the mouse button before dragging. If I just depress the mouse button and immediately drag, the box is moved. If I depress the mouse button, wait a second, then drag, the box correctly resizes.
I don't manage to reproduce the problem, with LibO 4.2.0.3 on Win7. If I click on the text, I get a blinking edit text cursor after the text, and no blue handles light up. If I click on the text box but not on the text, I get the handles. I noticed in recent LibO versions a growing number of case where the display is updated within a perceptible delay (more than 1 second). So I supposed that the initial action of the drag&drop is processed by multiple threads, one very reactive catching the pointer position and resulting in a "move" decision, and another less reactive catching the new pointer position and updating the display to "resize" shape (or something like that ; the LibO delelopers will know...). Anycase, this is a bug. It would be interesting to look for a correlation with the computer overall workload (for instance detecting more frequent cases like the current one when LibO is used through CITRIX).
for me not reproducible with LO 4.3.2.2 (Win 8.1) If I reselect the text box I get a border around with eight blue squares. Clicking on them I can resize the text box as expected.
Could not be reproduced on Slackware 14.1 LO 4.4.0.0.alpha1 Repro steps: -Followed the instructions listed by Dr Michael Brooks. I tried to resize the text box when making a new one, and when I saw the resize cursor, the text box resized normally. I also tried clicking with the resize cursor and immediately moving the mouse, and still it resized. Setting to RESOLVED. http://www.libreoffice.org/download/libreoffice-fresh/ If you can still reproduce it with the modern builds, go ahead and set the status back to UNCONFIRMED.