Download it now!
Bug 35079 - EDITING: Drawing element completely in mouse selection frame not selected
Summary: EDITING: Drawing element completely in mouse selection frame not selected
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected)
3.3.0 release
Hardware: x86 (IA32) All
: highest major
Assignee: Lennard Wasserthal
: 46360 48281 51205 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
Reported: 2011-03-06 23:52 UTC by Rainer Bielefeld Retired
Modified: 2012-09-15 11:19 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Sample document (15.71 KB, application/
2011-03-06 23:52 UTC, Rainer Bielefeld Retired
Drawing showing issue clearly (9.75 KB, application/
2011-03-12 11:07 UTC, Jeroen
Network diagram example (11.88 KB, application/
2012-03-12 05:57 UTC, dhowland
Description of how the problem occurs (197.34 KB, application/pdf)
2012-07-04 06:38 UTC, Rafael Lima
Original LO Draw file used to describe the problem (9.79 KB, application/
2012-07-04 06:39 UTC, Rafael Lima
PNG file generated after exporting the drawing (6.14 KB, image/png)
2012-07-04 06:40 UTC, Rafael Lima
Artefact ABB35079 is moved by svdtrans (6.95 KB, image/gif)
2012-07-15 13:52 UTC, Lennard Wasserthal

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-03-06 23:52:55 UTC
Created attachment 44188 [details]
Sample document

With "LibreOffice 3.3.1  – WIN7  Home Premium  (64bit) English UI [OOO330m19 (build 8 / tag]" (and more early versions)  it's hard to select elements. Although the complete little drawing is within the mouse selection frame, it will not be selected after you will have released the frame.

Steps to reproduce:
0. Open attached sample
1. <control>+<a> to check what the complete DRAWING might be. You will see 
   control points for the small 28x8 mm Drawing
2. <esc> to unselect
3. Try to select complete little drawing, for that create a selection frame
   with the mouse pointer. Click app. x/y 20/30 and drag mouse pointer with 
   pushed left button to app. 70/60
   A selection frame will be shown 20/30 - 70/60 that includes the complete
4. Release mouse button
   expected: complete drawing within selection frame will be selected
   actual: only circle with "Y" and small bar at the left to the rectangle
           with the flaps will be selected, rectangle with flaps remains 

You will have to span a really very big selection frame to get all Drawing  selected, that makes it really difficult to select parts of a bigger drawing.

It seems that the problem is caused by rotation of parts of the drawing. If you click the rectangle, rotate (around center) clockwise 90°, click the 3 flap elements and also rotate (around center) clockwise 90°. Afterwards you can select that rectangle with contents or also including the Y-Circle without problems.

I can not remember to have seen that with OOo 3.1.1 (I will check soon), but I see the same problem with OOo 3.4-dev
Comment 1 Jeroen 2011-03-12 11:07:57 UTC
Created attachment 44401 [details]
Drawing showing issue clearly

I can reproduce this issue in LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice- on Windows xp, as follows,

1. Open new drawing;
2. Draw a shape from Basic Shapes (eg. a rectangle);
3. Try to select the shape by covering it with a mouse selection frame. That will work;
4. Now rotate the shape by pressing right mouse -> Position and Size -> Rotation Angle -> Angle: 90 degrees;
5. Try to select the shape again by covering it with a mouse selection frame. 

Expected: the shape can be selected with a frame slightly bigger than the shape.
Actual: the invisible bounding box appears to be extended somewhere south of the shape, so the shape cant be selected by a selection frame just around the shape.

Note that this bug doesnt occur with the Rectangle (the one not from the basic shapes).

I added a picture where the estimated extension of the bounding box of a rotated rectangle (from basic shapes) is marked with a dashed rectangle (you can find the bounding box by clicking on the shape and hovering over the paper; the cursor will change when it hovers over the bounding box).
Comment 2 Björn Michaelsen 2011-12-23 11:43:10 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation:
Comment 3 Zilvinas 2011-12-26 12:15:04 UTC

I can confirm that this bug is reproducable in LibO 3.5 beta2. The bug is likely of the same source as one described in OpenOffice bug# 102496. A selection failure exists not only for shapes but also for very basic drawing element like a connector (LibO 3.5 beta2 also). This makes a work with Draw application very frustrating up to unusable.

This is my findings on selection failure for a connector.

1. Draw a connector line (for example, from lower left (start) to upper right (end).
2. Selecting the connector by clicking it in all its points or by selection area around it works perfectly.
3. Move upper end (end) down below its lower end (start).
4. Try to select it. Nope! You can't, except at the very proximity to the upper end (start). Selection by area is not working at all.
5. Select connector by clicking on the very upper end (start) and move that end a bit down. From now on you have no chance to select connector at all.

Even workaround exist, it in not in favour of Draw usability. You can use selection by area around old position of the connector to select it (if you still remember where it was originally).

Seems like some shape modifications (rotation, etc?) or movement of connector's ends fools selection data of the element.
Comment 4 dhowland 2012-03-12 05:56:47 UTC
I also show this bug in 3.5.0 on Windows.  In addition to making selection with a mouse annoying, this bug causes problems when exporting a selection.

For example, attempt to export the network diagram attachment to a .PNG.  Use CTRL+A to select the entire diagram, and note the location of the bounding box.  Then use export and check the "selection" option.  The resulting image will contain extraneous empty space.
Comment 5 dhowland 2012-03-12 05:57:50 UTC
Created attachment 58313 [details]
Network diagram example
Comment 6 dhowland 2012-03-12 06:02:51 UTC
*** Bug 46360 has been marked as a duplicate of this bug. ***
Comment 7 Rainer Bielefeld Retired 2012-03-12 07:17:02 UTC
I also see problem with 3.3.0
Comment 8 Frédéric Buclin 2012-04-23 16:31:42 UTC
I can also reproduce with LibO on Linux. This makes me crazy, especially for files which contain several draws (because you cannot use Ctrl+A, else you would select all draws). This is a severe regression.

Is there a way to bring this bug to the attention of LibO developers for 3.5.3?
Comment 9 Regina Henschel 2012-06-18 13:29:07 UTC
*** Bug 48281 has been marked as a duplicate of this bug. ***
Comment 10 Regina Henschel 2012-06-18 13:29:47 UTC
*** Bug 51205 has been marked as a duplicate of this bug. ***
Comment 11 Lennard Wasserthal 2012-06-28 01:56:52 UTC
Bug doesnt't occur on self-drawn shapes
Hence I guess that the clipart shapes have a fine and a coarse bounding box, the latter of which is intended to speed up things and is calculated wrongly and is ignored when clicking the shapes directly.
Comment 12 Lennard Wasserthal 2012-06-28 02:09:18 UTC
Even if its converted from a clipart shape to a polygon shape, the error ceases to occur. However, at least what the double arrow, the moon, the rhomb and the stars are concerned, additional points do appear in the corners between shape and bounding box.
To bad we have no lasso tool.
Comment 13 Rafael Lima 2012-06-28 13:25:15 UTC
I am also having the same problem, which makes it very frustrating to use LO Draw. I noticed that the problem happens when I rotate a shape.

Every time I have a shape rotated, I cannot select it... It seems that, in the background, LO keeps the original position and area of the shape. And when I export the image to PNG or JPEG, it includes a undesired blank space.
Comment 14 Lennard Wasserthal 2012-07-02 11:51:37 UTC
I cannot reproduce that- What Version? What OS? (What Processor?)
It would be interesting how it looks like-could you include such a jpeg file
(Best one where you can select the whole scope of the rectangle???)
Comment 15 Rafael Lima 2012-07-04 06:38:44 UTC
Created attachment 63804 [details]
Description of how the problem occurs
Comment 16 Rafael Lima 2012-07-04 06:39:39 UTC
Created attachment 63805 [details]
Original LO Draw file used to describe the problem
Comment 17 Rafael Lima 2012-07-04 06:40:43 UTC
Created attachment 63806 [details]
PNG file generated after exporting the drawing
Comment 18 Rafael Lima 2012-07-04 06:44:00 UTC
Lennard, I am using LibreOffice (the latest version in repositories). My processor is an Intel i5 64bit and my OS is Ubuntu Linux 64.

I attached three files describing how the bug occurs. First is a PDF file describing the steps to reproduce the bug. The second file is the ODG file I created while writing the bug description. I also included the PNG file exported by LO with the blank spaces I mentioned.

Hope it'll help!


(In reply to comment #14)
> I cannot reproduce that- What Version? What OS? (What Processor?)
> It would be interesting how it looks like-could you include such a jpeg file
> (Best one where you can select the whole scope of the rectangle???)
Comment 19 Lennard Wasserthal 2012-07-15 13:52:39 UTC
Created attachment 64238 [details]
Artefact ABB35079 is moved by svdtrans

@Rafael Lima: Thanks a Lot.

Of course, I can reproduce it. I just understood it differently.
It ONLY occurs when you export a selection. Additional Bounding Box (lets call it ABB35079) is always to the right of the shape.
Obviously, there is some coordinate Information ADDED to the Shapes - Information that isn't rotated.
But it must be shifted during rotation. the additional bounding box seems always to be on one end of the Figure.
(the end that was the left one before the rotation)

I (initially) thought the bounding box was checked - in unrotated state - BEFORE the fine selection was done, just like a coarse check.

But as there is not such a coarse check amongst the selection it turns out that the respective bounding box seems to be additional geometry information INSIDE the shape.

If you mess up the positioning by defeating the rotating routine in /svx/..../svdtrans.cxx, the selection frame is shifted and the >>Additional Bounding Box<< ABB35079 is shifted with it, too!
(since now, the rotation selection is not rotated, it is identical now to the >>Additional Bounding Box<< i call ABB35079. So the ABB35079 must be something that is shifted by the svd rotating routine.
(While the VISIBLE Data Structure is rotated by something else).
(See picture).

My Questions:
(Where is the routine that defines the standard shapes?) I guess i'll find out...
What is the difference between userdrawn/=converted curves and standard shapes?
Where is the routine that rotates the shapes?
Comment 20 Lennard Wasserthal 2012-08-04 08:22:50 UTC

I found out that if you 
Change in

drawinglayer/source/primitive2d/baseprimitive2d.cxx    # Line Nr about 127 in my git


basegfx::B2DRange getB2DRangeFromPrimitive2DReference(const Primitive2DReference& rCandidate, const geometry::ViewInformation2D& aViewInformation)

in a way that after

You add the further condition
                if ((dynamic_cast< BasePrimitive2D*>(rCandidate.get()))->getPrimitive2DID()!=45) // Excludes auxiliary selection shape which is wrongly rotated
the Problem ceases to exist.

Should I submit this now, or should I first watch what adverse effects this brings with itself?
Comment 21 Rainer Bielefeld Retired 2012-08-05 17:18:12 UTC
Lennard Wasserthal:
If you are uncertain you should discuss your patch on <>
Comment 22 Lennard Wasserthal 2012-08-11 18:33:58 UTC
Fixing this bug this way causes the program to crash when exporting jpeg's

better use 61 ,,PRIMITIVE2D_ID_HIDDENGEOMETRYPRIMITIVE2D'' instead of 45.

I guess I can release this patch now.
Comment 23 Lennard Wasserthal 2012-08-14 16:01:39 UTC
Sorry for not writing PRIMITIVE2D_ID_HIDDENGEOMETRYPRIMITIVE2D instead of 61. but the pusher fixed it.
Patch submitted under MPL/LGPLv3.

Setting the Status to fixed
Comment 24 Lennard Wasserthal 2012-08-22 09:25:49 UTC
The bugfix had bad side-effects. breaking slide transitions. Perhaps i descended too much into the inner guts of the program.
Comment 25 Lennard Wasserthal 2012-08-30 19:50:48 UTC
OK, this should do it. Thorsten said I sould make a new id for that frame object, but since the current principle is that any ID belongs to a class and that would be extreme code duplication and sister classes also got flags, I add a flag that tells if it is a hiddengeometry from a customshape or from something different.
Besides, I would have to find and change any piece where the hiddengeometry is REALLY used. 
But now, I really carefully check whether I broke something.
Comment 26 Lennard Wasserthal 2012-09-15 11:19:32 UTC
Obviously, the ,,invisible outline for the cases where no visible content exists''
was the problem, as it didn't work with the way custom shapes are rotated.
I deleted it. It seemed to bring no problems with exported files. (checked with MS Office Professional 2012)
Somehow, i didn't see the comment what the object was for before I submitted it. - ????