Description: When editing a chart using the sidebar, the sidebar is unresponsive and so cannot be used. Seems to be the case when creating new charts and opening old ones, both docx and odt. Observed on Win10 LO 6.1.0.3 Steps to Reproduce: 1. Open Calc 2. Create a chart (e.g. enter 1,2,3 in A1-A3 and B1-B3 then create a scatter graph) 3. Double click into the graph to go into edit mode 4. Go into the sidebar to edit. Actual Results: Nothing.... Expected Results: The buttons do their function, e.g. change the colour of the scatter points. Reproducible: Always User Profile Reset: Yes Additional Info: Opening a pre-existing chart also doesn't work
Bug also present when editing a chart pasted into a docx/odt file - same LO version.
Created attachment 144313 [details] Screenshot side bar for chart OpenGL disable. Same behavior wit OpenGL enable. With OpenGL disable instead nothing it's like select styles. Attached screenshot.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=10e4528e8cb9818e7b8fcef8b1e96985f8b28640 author Katarina Behrens <Katarina.Behrens@cib.de> 2018-03-06 12:17:07 +0100 committer Katarina Behrens <Katarina.Behrens@cib.de> 2018-03-19 12:09:53 +0100 commit 10e4528e8cb9818e7b8fcef8b1e96985f8b28640 (patch) tree 5f2d336afbe21e5ca834618f4a974d79b7ab8602 parent d05ee87bdd779a8d799269af4bb45ae8a4ea3150 (diff) tdf#115806: Remember last active deck also on context switch within 1 application Bisected with: bibisect-linux64-6.1 Adding Cc: to Katarina Behrens In order to bisect this issue, I did it with a clear profile on every step. After 10e4528e8cb9818e7b8fcef8b1e96985f8b28640, the sidebar works the first time I select the chart, if I deselect it and select it again, it no longer works...
Can also reproduce this with a given chart in an ods with Win7/Libo 5.2.0.4 Workaround for color, trancparency and line/border: use the classic menue Format -> Format selected object (first entry in the menue Format)
*** Bug 119870 has been marked as a duplicate of this bug. ***
Since there's an additional info in the dupe (sorry about duplication, I hadn't found this one...): * The regression is earlier than the one in the bibisection (Comment 3), actually it's at least two regressions. * Initial regression is between 5.4.7.2 and 6.0.6.2 (edit works for first edit, but unresponsive after leave-enter, in 5.4 it works) * Second regression is the one that was bibisected. * The problem noted in Comment 4 is probably Bug 100180
Unless I made a mistake (it's my first bibisection), it seems like the first regression is caused by this commit (bibisect-linux-64-6.0): 897245ca0ff3c8ce47b678214fb70326fdbed2ce is the first bad commit commit 897245ca0ff3c8ce47b678214fb70326fdbed2ce Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Apr 9 21:17:04 2018 +0200 source 2c51260d91490a6fc512875d8befb38367bf3227 source 2c51260d91490a6fc512875d8befb38367bf3227 :040000 040000 93920d0559b6566bd3e4b044b3263740026e2caa 83370c22b7eb32bff6ffa8cc4e0d83dc490a34a5 M instdir
(In reply to Martin Sourada from comment #7) > Unless I made a mistake (it's my first bibisection), it seems like the first > regression is caused by this commit (bibisect-linux-64-6.0): > > 897245ca0ff3c8ce47b678214fb70326fdbed2ce is the first bad commit > commit 897245ca0ff3c8ce47b678214fb70326fdbed2ce > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Mon Apr 9 21:17:04 2018 +0200 > > source 2c51260d91490a6fc512875d8befb38367bf3227 > > source 2c51260d91490a6fc512875d8befb38367bf3227 > > :040000 040000 93920d0559b6566bd3e4b044b3263740026e2caa > 83370c22b7eb32bff6ffa8cc4e0d83dc490a34a5 M instdir Seems like I *made* a mistake, not sure where though :( Since the source commit seemed very unlinkely to blame, I tried hard resetting the repo and bibisecting again, with double checking every step and resetting user profile in each try. The "correct" bad commit seems to be: 790f6ffe130014691c5fc7473bebde812903eec9 is the first bad commit commit 790f6ffe130014691c5fc7473bebde812903eec9 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Apr 12 21:31:47 2018 +0200 source afaa944633cb94205fb835c1d93775fa51ead749 source afaa944633cb94205fb835c1d93775fa51ead749 :040000 040000 76dd577dbc02604c3d1d8b6b8c80a1b752030b5a a2f86bcd7804c1883ef9b4a25bfdee351f10043a M instdir aka diff options context: space: mode: author Katarina Behrens <Katarina.Behrens@cib.de> 2018-03-06 12:17:07 +0100 committer Caolán McNamara <caolanm@redhat.com> 2018-04-12 17:19:45 +0200 commit afaa944633cb94205fb835c1d93775fa51ead749 (patch) tree b07c3a8aea487481760c074d3b3946ee4462e586 parent a7e8fa20d8c1a529ef3cd7f69d3afa2e06412800 (diff) tdf#115806: Remember last active deck also on context switch I'm sorry about the confusion.
*** Bug 120110 has been marked as a duplicate of this bug. ***
reproducible with lo 6.1.1.2 but i can no longer confirm this issue with upcoming: Version: 6.1.2.1 (x64) Build-ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc:
I can still reproduce this bug with: Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: en-GB (en_GB); Calc: CL It's interesting that Oliver Brinzing cannot [Comment 10].
Im Caolan fixed this in https://cgit.freedesktop.org/libreoffice/core/commit/?id=542a9a340972da7739c33465620ffe48da8745dd but please retest
For me it still doesn't work properly in 6.3.0.0.alpha0+ (67e062aa5e5946d4985921fe2b6f87766f363ddc) / Windows 7. However, what I see doesn't seem to be a regression from the mentioned commit, as I can reproduce even with 5.1.0.3, when the chart sidebar was introduced. My steps (based on description): - Have sidebar open, but no decks open initially. - Create a chart, and click into it. (=> Bug 1: list of sidebar decks isn't updated, it should only show Properties) - Select an element, eg. the label. - Open Properties deck, and click anywhere on it. => It behaves as if you selected a cell in the sheet where you clicked. This only happens if you entered the chart with no open deck/sidebar. However, if you entered it with an open deck/sidebar, and attempt to hide it, its empty space will remain on the screen. It isn't exactly what Miguel Angel's screenshot shows, but is likely related.
I don't fully reproduce this in: Version: 6.3.0.0.beta1 (x64) Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded For example I can change the colour of things. I can turn on subtitle but I cant turn it off. Performance is very jumpy. But it doesn't act as if you've clicked the cell below the sidebar as it did before. Next time ive access to a Linux machine I'll retest on there as well.
I cannot therefore reproduce the observations of Comment 13. I only get the properties icon in the sidebar. Thanks for the updates and the commit!
There are at least three bugs on various issues with the chart sidebar appearing broken in some cases: bug 94322, bug 103109 and bug 115147. And it can seem as it's not working/broken, because of the broken appearance, eg. as shown in attachment 144313 [details]. I'm marking this bug as WORKSFORME, because the steps are now different, and not about the original issue. If there's an issue that doesn't fit in the above 3 bugs (ie. anything concerning actual behavior of the chart sidebar controls), please open a new bug report.
(In reply to Aron Budea from comment #16) > appearing broken in some cases: bug 94322, bug 103109 and bug 115147. And it > can seem as it's not working/broken, because of the broken appearance, eg. > as shown in attachment 144313 [details]. I wasn't precise at referring to this attachment as this particular case is probably fixed by the commit mentioned by Katarina in comment 12. However, if you first close the sidebar, double-click the chart, then open the properties sidebar, you will see underlying cells shown in some places, and other oddities, which fit the mentioned bug reports.