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
Confirming on master build 4.2.0 alpha on OSX 10.8.4
Created attachment 82192 [details] apple crash report when changing label name after multiple select DnD
The trace looks similar to what I see in fdo#66700
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.
Created attachment 82207 [details] test file
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...
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.
Adding self to CC if not already on
** 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
No repro Version: 5.0.3.2 Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale : fr-FR (fr.UTF-8) OSX 10.11.2 closing as wfm