Description: Some times formatting conditions cant be edited Steps to Reproduce: This happens frequently, but if you try it a second time or reopen the document it just works again. It wasnt easy to be able to reproduce it every time :) 1. Open the attached document 2. select B3. Format> conditional formating> manage 3. select B3:B37 range and click edit, then click yes Actual Results: It goes back to manage conditions Expected Results: Editing the range Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Created attachment 130701 [details] document to reproduce bug
I reproduce. I already tested on Windows earlier. Version 5.0.2.2 does not ask "do you want to edit" and it goes straight to editing. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 63fd4c97118a943c84ba5a666cf8c9cc54b511c7 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on January 22th 2016 Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.4.2.0+ Build ID: 5.2.4-2 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group
e95c186bc83eaea3cf81a731020ce36f7ed4b72b is the first bad commit commit e95c186bc83eaea3cf81a731020ce36f7ed4b72b Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Sep 30 08:21:44 2016 +0200 source 5b8c22379e2eae74f7ed78326ab89483db5c6624 # bad: [8c41dca5bdcdd16586b77dc014de74f2d17e6bdd] source 843b9d5dba5098c2676491dda66bed31e57f4329 # good: [33e60eae04c889baf52713a73dc9944015408914] source 5b168b3fa568e48e795234dc5fa454bf24c9805e git bisect start '8c41dca' 'oldest' # good: [13329e8dde9d4b8befeb35729bdb02c58a4ae324] source 82ce1d2cd27f7d6fe8046a74d0b7d8866b75c458 git bisect good 13329e8dde9d4b8befeb35729bdb02c58a4ae324 # good: [e378c02823765b4028ef4c32245d27b7fad01ef8] source cc497d86e092315f78a89f3ace8b81623dad7b46 git bisect good e378c02823765b4028ef4c32245d27b7fad01ef8 # good: [64fb5be3c5095b0f89fbd425d982573088005ba4] source 0f2d5db38bac64b665c6e4a127bbbd63a7ed9af5 git bisect good 64fb5be3c5095b0f89fbd425d982573088005ba4 # good: [df2850548fef1cdfaa378ce9771e4d6dbadfbcb8] source 0f33526ec27a3abcfa1ca9348a46238b1432e5e4 git bisect good df2850548fef1cdfaa378ce9771e4d6dbadfbcb8 # bad: [6df02c7e421fb59485173f89bcc87bbf31e6cc33] source e58324aaca6875dbfe7c6c8333d747d2bfd9d089 git bisect bad 6df02c7e421fb59485173f89bcc87bbf31e6cc33 # good: [9dd6bd752611ef9bef3695856327fb428b1c1c82] source 5fb8a050210a7cabf49daac0da8f80b94d60de2c git bisect good 9dd6bd752611ef9bef3695856327fb428b1c1c82 # good: [1862f95176b58b1964276d02fbdd71185b78b627] source 55fcc386401bca573a95bfed37a3de687f83884c git bisect good 1862f95176b58b1964276d02fbdd71185b78b627 # good: [9925564f5043378fe0a6acaf82daff4e45902cce] source c57e7685f22c4b010a7ddb25fa896f8405e95818 git bisect good 9925564f5043378fe0a6acaf82daff4e45902cce # good: [04181905938ef308f17ae6fa26d2666317e12ade] source c9805c52264eb99b3d73f9038da716ac94501502 git bisect good 04181905938ef308f17ae6fa26d2666317e12ade # bad: [aa995b3c493bf8ee9c46029bdf186d041c2b272a] source 2d31990ad0806e74f92841fb8f87db101e1a8fc3 git bisect bad aa995b3c493bf8ee9c46029bdf186d041c2b272a # bad: [e95c186bc83eaea3cf81a731020ce36f7ed4b72b] source 5b8c22379e2eae74f7ed78326ab89483db5c6624 git bisect bad e95c186bc83eaea3cf81a731020ce36f7ed4b72b # good: [f507e34f7463b6f956d09f788178589ca4279d02] source 96646c351e20fa6699fa368457a05ee70f76f103 git bisect good f507e34f7463b6f956d09f788178589ca4279d02 # first bad commit: [e95c186bc83eaea3cf81a731020ce36f7ed4b72b] source 5b8c22379e2eae74f7ed78326ab89483db5c6624
Bibisect results point to the commit referenced below. Adding Cc: to Markus Mohrhard, please take a look. https://cgit.freedesktop.org/libreoffice/core/commit/?id=5b8c22379e2eae74f7ed78326ab89483db5c6624 author Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-09-18 14:14:35 (GMT) committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-09-19 10:10:09 (GMT) "tdf#96453, tdf#100793 rework transfer of data between cond format dlgs"
Hallo, it works in 5.3.0.3 better but not fine! If I want to edit conditions second time the program don't return to the list of condition. I will demonstrate it on the same file: 1. Open the attached document 2. select Y9. Format> conditional formating> manage 3. select C3:BA100 range and click EDIT, 4. Answer the question with YES 5. Now edit the conditions and click YES or CANCEL now it returns to list of conditions 6. select C3:BA100 range again and click EDIT, 7. Answer the question with YES 8. Now edit the conditions and click YES or CANCEL now it does not return to list of conditions!
Aron, since Bug 96453 is still open, why would this be a new bug? Do you think this one may be closed as a duplicate?
(In reply to Timur from comment #6) > Aron, since Bug 96453 is still open, why would this be a new bug? > Do you think this one may be closed as a duplicate? Bug 96453 is a different issue, and the partial bugfix for that issue caused this one. We can't be certain finishing that fix will get rid of this bug as well, therefore it's safer that this one has its own report (and bug 105114, too).
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0b9e33cceb635cd3c173bd1f461af98cfd6f6ed2 don't forget to set the managed flag, tdf#105544 It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d9128bc895bfa9740cd85c766a10217e35aaa937&h=libreoffice-5-3 don't forget to set the managed flag, tdf#105544 It will be available in 5.3.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I found this behavior on 5.3.1 1.) A range (let's say A1:A7) is formatted with an condition. Set cursor somewhere into that range and select: >Format > Condition... A Dialog pop's up and Tells me: "The selected Cell already contains...." "Do you want to edit the existing conditional formatting..." When select "Yes" it shows me a blank dialog where I can define a new condition. I have to remember and select the whole range of A1:A7 to access the existing conditions. 2.) If a Document created with a previous Version of LibreOffice exist and I want to Add or Edit an a condition, the dialog as described above pop's up and ask the Question whether I wanna edit existing conditions or not. When hitting "Yes", a list of existing conditions are shown in a list. I select one, click [Edit] and the dialog disappear and the original one with the Question whether I wanna edit existing conditions or not appears again. ... endless loop without any chance to access my entered conditions. I have to remove all of them before I can enter an new one into the desired range.
*** Bug 105114 has been marked as a duplicate of this bug. ***
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae0d1f3af9ae129c3a7d98a544e0c9b0c30659c7 uitest for bug tdf#105544 It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The test exist, set status to Verified.