1. Open a new writer doc, create a table 2x2 2. Select the cells, Press F12 and all cells are numbered '1.' Expected behaviour: Cells will be numbered 1 to 2 Left to Right on Row 1, the 3 to 4 on Row 2 e.g 1. |2. ------ 3. |4. Actual behaviour: Cells are *all* numbered 1. Additional info: a. selecting cells individually & pressing F12 will have numbering increment as normal. b. If the bottom row of the table is selected and a new row inserted, each subsequent row increments *all* cell numbering in that row by one. c. Numbering works as expected in Ubuntu 14.04 64bit 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Importance switched to high as this is a regression from 4.2.4.2
Ubuntu 14.04 LibreOffice 4.3 beta1 LibreOffice 4.2.4.2 release (works) d97d068402198fd528087c954ff8bf7fc2380a77 is the first bad commit commit d97d068402198fd528087c954ff8bf7fc2380a77 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon May 12 01:37:21 2014 +0000 source-hash-3d1b1eea83703919c43620f9adef05e5b24c4bed commit 3d1b1eea83703919c43620f9adef05e5b24c4bed Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Mar 19 12:27:07 2014 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Mar 19 15:37:56 2014 +0000 coverity#735757 Unchecked dynamic_cast Change-Id: I268b9c4df81598f68b8da2c258d70c2118b69d82 :100644 100644 55e483c4a724436ee0e792f72b90a3d301c77064 46da6ac1f330f20bd0a4ebebe27910e2c0e49e49 M ccache.log :100644 100644 109c99441737bb49205950d8d26f994ab7ade8ca 88c019e4e1f3e2591ad255a84ebb468863e18b3f M commitmsg :100644 100644 489b61544cecbe2b2fc066ce04098712be6374d8 80fe30beee6868b7ef681d3d1040c51b252661ea M make.log :040000 040000 8d40ab0ff1362b98fa7646afb94a246acb54cd98 fe475bf82129a0a85c90230737d704d41ab77938 M opt # bad: [a92705c1fabafddd43d175a0714855cd22551232] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [6ab7f53af36f13bbefdd4e4fcbd3d1ea432a77d9] source-hash-22029c7e17b4cb48acb058d47ec9c3b6b8b6b294 git bisect start 'latest' 'oldest' # good: [bebf9d31c8fe9de96798484288a0fffc4d54917d] source-hash-09e5de8278dd8f13adcf614db35c8a8a04ba8e47 git bisect good bebf9d31c8fe9de96798484288a0fffc4d54917d # bad: [fac643700ecfabc737836bbed068776f34037d53] source-hash-40a61d93ade494fa98c23a9fd8776c8dadf8f30f git bisect bad fac643700ecfabc737836bbed068776f34037d53 # bad: [d97d068402198fd528087c954ff8bf7fc2380a77] source-hash-3d1b1eea83703919c43620f9adef05e5b24c4bed git bisect bad d97d068402198fd528087c954ff8bf7fc2380a77 # good: [3028c93bb1bec9aadbc210f29569c0b30b8cfd45] source-hash-3f0a8dc3c8204d6a500a5da64ad57996d593022f git bisect good 3028c93bb1bec9aadbc210f29569c0b30b8cfd45 # good: [469dea83beaa20dde4b6d71e9520adbbed0925ca] source-hash-077a74cfc6dbea5ee275fd11b65b523cc525e2e4 git bisect good 469dea83beaa20dde4b6d71e9520adbbed0925ca # good: [6dd9bc7210a274f38aef21edadb10cab192d3759] source-hash-1eb20c97e4d0f644efcf46aedac619a9765488c3 git bisect good 6dd9bc7210a274f38aef21edadb10cab192d3759 # good: [9e287f0939791627cc5cb0372043277178eb0155] source-hash-77b6c1602aaa0bd059077765e7fabb53d9e6ddeb git bisect good 9e287f0939791627cc5cb0372043277178eb0155 # good: [929bc545099fc56ac8e76ecfb0a6ed9807e2542e] source-hash-7b56d303300fbf592473b28b654fd22fec110962 git bisect good 929bc545099fc56ac8e76ecfb0a6ed9807e2542e # first bad commit: [d97d068402198fd528087c954ff8bf7fc2380a77] source-hash-3d1b1eea83703919c43620f9adef05e5b24c4bed
it's caused by commit 04187aaf09969341a7ae9ae7ff5a13925381a96b ... but at first glance i'm not sure which of the 2 ways to create the lists is the correct one.
This bug is still present in Version: 4.3.0.3 Build ID: 08ebe52789a201dd7d38ef653ef7a48925e7f9f7 I've changed 'Version:' to highest available in the dropdown box.
changed to Version '4.3.0.3rc' now it is available in the list box.
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
What's next step since 'a commit is suspected as the offending one.'
The next step is to wait until someone has the time to dig into it more. Patience is part of the open source world :-D
As per comment 3, it is unclear if the old or the new behaviour is actually the right one. Setting to NEEDINFO for clarification from UX ...
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-09-03
This now works as expected in LO 4.4.5.2 & LO 5.0.1.2.
I just checked and this bug has indeed been fixed Tested on Windows 10 64-bit LO: 5.0.3.2 full specs: http://valid.x86.fr/6vh0d4
setting resolution to WORKSFORME as we don't know what exactly fixed it
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]