Download it now!
Bug 61380 - REPORTBUILDER: Report Builder crashes when attempting to reposition and modify field description in the body of the report.
Summary: REPORTBUILDER: Report Builder crashes when attempting to reposition and modif...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.5.2 release
Hardware: All All
: high critical
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-24 06:39 UTC by Dan Carr
Modified: 2016-01-19 13:39 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
apple crash report when changing label name after multiple select DnD (73.04 KB, text/plain)
2013-07-08 15:06 UTC, Alex Thurgood
Details
test file (7.54 KB, application/vnd.oasis.opendocument.database)
2013-07-09 03:10 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Carr 2013-02-24 06:39:02 UTC
Problem description: 
Using the report wizard I created a 3 column report with 100+ fields.  Before creating the report, I selected edit and was able to move 15 fields two at a time (label field and data field) to the header portion of the report leaving 85+ label & data field pairs in a 3 column body.  When I reopen the report for editing, select multiple fields, move the selected fields, then attempt to modify label contents, the application crashes.  I am able to select a label field and the data field and move them together to the desired position. I then deselect the fields and attempt to change the contents of the label when I press enter to change the contents the application crashes. 

Steps to reproduce:
1. Create a 3 column report using the report wizard
2. Save the report
3. Open the report for edit
4. Select multiple fields (label & data) using the Control key and cursor 
5. Move the selected fields to an open portion of the report. 
5. Deselect the fields
6. Select one label field and modify the contents.
7. Press enter to make the change and the application crashes. 
8. Message is presented saying the application has crashed and open files will be saved.  

Current behavior:
I have been able to move individual fields, modify the contents and/or the length. If I select multiple fields to move, after deselecting the fields and attempting to modify, the application crashes. 

Expected behavior:
Allow multiple fields to be selected, moved as a group, deselected and then individually modified. 


              
Operating System: Windows 7
Version: 3.6.5.2 release
Comment 1 Alex Thurgood 2013-07-08 15:05:19 UTC
Confirming on master build 4.2.0 alpha on OSX 10.8.4
Comment 2 Alex Thurgood 2013-07-08 15:06:13 UTC
Created attachment 82192 [details]
apple crash report when changing label name after multiple select DnD
Comment 3 Alex Thurgood 2013-07-08 15:07:32 UTC
The trace looks similar to what I see in fdo#66700
Comment 4 Lionel Elie Mamane 2013-07-09 03:09:46 UTC
Cannot reproduce on my master (4.2.0.alpha) dev-tree (own build) of commit (build-id) c63b74d22d360893bb9e1200f59099ffb7943705 of 2013-07-03 21:36:58 on Debian GNU/Linux amd64. Also cannot reproduce with LibreOffice 3.5.4.2 (Debian package).

Alex, could you try on your GNU/Linux install?

Alex and/or Dan, please give detailed reproduction instructions. Here's what I did:

1) open the "test file" attachment.
2) edit the "assets" report
3) Select label and formatted field of AssetCategoryID, BarcodeNumber, Comments.
   That is, six controls in total.

   Note: I have to use the SHIFT key for that, not Control like original
   reporter. Maybe that's a difference between MS Windows and GNU/Linux?

   I keep the shift key pressed, and then click one on each of these controls.
4) Point the mouse cursor on one of the selected controls, press the mouse
   button, don't release it, move the mouse down.

   The block of six controls moves down.
5) Release mouse button.
6) Click on blank area of report (e.g. below "Model", still in the Details
   section) to deselect all fields.
7) Click on "AssetCategoryID" field
8) In the properties pane on the right, in the "Label" property, add a space
   between the words, changing to "Asset Category ID".
9) Press enter

No crash for me.
Comment 5 Lionel Elie Mamane 2013-07-09 03:10:33 UTC
Created attachment 82207 [details]
test file
Comment 6 Alex Thurgood 2013-07-11 07:33:57 UTC
Can not reproduce on Linux 32bit master build :

Version: 4.2.0.0.alpha0+
Build ID: 5d6bfead080f31c421c4b236e3d6f2a9e8118b97

This would appear to be Windows/Mac specific...
Comment 7 Alex Thurgood 2014-11-26 10:17:50 UTC
This bit me on the bum again on Thur night when using production release 4331 on Mac OSX Yosemite. I had forgotten about it.

Basically, repositioning a grouped oject "field and corresponding label" from its default position using drag and drop will cause LO to hang on OSX.

The reason this is at all necessary, apart from being a desirable functionality, is that the default positioning of the grouped object when dragging a field from the "Add field" dialog window is to put the label about an inch vertically under the corresponding data field. This behaviour is, of itself, really annoying (there might already be a bug report somewhere for this, I don't remember), which means that the user then has to move either the grouped object to the desired position in the report, or else has to enter the grouped object and then move one or the other of the label or data field to the desired position (usually the label). Whilst this works for the first few fields added to a blank report, adding further fields and then attempting to move them causes LO to hang and then crash. The reason it hangs first for seemingly ages on OSX is because when an app crashes in this way, the built-in OSX system crash reporter samples the call stack to obtain a trace.
Comment 8 Alex Thurgood 2015-01-03 17:39:44 UTC
Adding self to CC if not already on
Comment 9 QA Administrators 2016-01-17 20:05:34 UTC
** 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.0.4 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: 2016-01-17
Comment 10 Alex Thurgood 2016-01-19 13:39:59 UTC
No repro 

Version: 5.0.3.2
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale : fr-FR (fr.UTF-8)

OSX 10.11.2

closing as wfm