Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Setup: In Properties side-bar, Cell Appearance section, the cell background color selection widget behavior has changed from earlier 7.x releases. The widget still offers a rectangular area where it used to immediately display a color sample grid upon widget activation. Now upon activation NO color sample grid is displayed but rather a drop-list selector for a palette. The drop-list initial value is "standard". After some experimentation I find that a palette selection is sticky to a given Calc file across Calc sessions. GOOD. The Bug: EXCEPT if what you want sticky is the old "standard" palette, the palette currently listed below palette "material" in the drop-list. The bug here is that there are TWO drop-list items named "standard". The one above "material" in the drop-liet has a NULL palette (no color sample grid). The apparent behavior is that the null palette named "standard" drop-list entry intercepts the top-down list search for the non-null palette named "standard" EVERY WIDGET USE, adding enormous negative-value click-work to this frequently used widget. BTW, your entire inventory of older Calc files mostly use the "standard" palette for which the click-work to use has now been doubled. Oops. In addition to removing the bogus null-palette "standard" drop-list entry I suggest the old "standard" (below "material") be re-named as "Calc standard" to give a better sense of what it is. Or perhaps "Legacy Calc" if the intent is to create a new Calc standard palette in the future. Regards.
>The bug here is that there are TWO drop-list items named "standard". I have only one "standard" item in that list in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ac80ec817eb07c77a51bc0729985a473c734182e CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded Can you retest your problem in 7.1 or 7.2 version?
The issue remains as stated in Version: 7.1.5.2 (x64) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded as well as the other LO apps that use this color picker interface. Attached two desktop screen caps.
Created attachment 173982 [details] Color picker I/F initial popup. LO v7.5.1.2 color picker I/F initial popup showing no-color-grid "standard" palatte.
Created attachment 173983 [details] Color picker I/F showing presence of 2 "standard" palatte entries. Color picker I/F showing presence of 2 "standard" palatte entries. The one in the middle of the picklist is the null grid version. The one below "material" has a color grid.
[Automated Action] NeedInfo-To-Unconfirmed
So strange. Can you reset your user profile using menu item Help-Restart in Safe Mode?
(In reply to Roman Kuznetsov from comment #6) > So strange. Can you reset your user profile using menu item Help-Restart in > Safe Mode? Restart in Safe Mode (no options selected) does restore the color picker I/F working as expected but of course without any palatte entries that may have been created by extensions. So then likely some extension install/update/uninstall horked the the color picker widget config in the user profile. Assuming this is the case, then 2 courses of recovery: 1) Uninstall all non-bundled extensions, re-start in Safe Mode and factory reset the profile, then re-start in normal mode and re-install extensions one-by-one checking the color picker widget each time. I have 8 extensions installed 7 of which are enabled. Painfull but doable. The advantage of this method is identifying if a particular extension install is reproductibly causing the config issue. 2) If the color picker config is in a text editable file buried in the <userhome>\AppData\Roaming\LibreOffice\4\user tree, then get that filename from this forum and take a look for possible manual correction without the work of #1. #1 would then be the fallback method. If the color picker widget config is stored binary, then back to method #1. Regards.
Please indicate if the color picker widget is configured via a text-editable file and if so its path in the user profile. Regards.
So, your "problem" was in installed extensions? Can we close it as NotABug?
(In reply to Roman Kuznetsov from comment #10) > So, your "problem" was in installed extensions? Can we close it as NotABug? Please indicate if the color picker widget is statically configured via a text-editable file and if so its path in the user or host-common profile. I suggest it is unwise to so readily dismiss this case as NotAbug. I happen to be a retired IT systems engineer with experince as both an IT vendor and an IT customer and I have some interest in contributing to LO bug root cause analysis and improving LO. I can tell you from my vendor experience that even if a bad extension or bad extension install process caused this color picker dysfunction, for the average LO user it still has LO's name on it especially if they do not associate the appearance of the dysfunction with an extension management event. For example, does LO provide an API for extensions to use to statically modify the user profile during install/first use/uninstall or conversely does LO call in to enabled extensions via an LO-spec API at startup to dynamically assemble the color picker? If so, why does that API not perform simple QA checks such as for palette namespace collisions across enabled extensions or enforcing LO-reserved names if any? Quality Assurance deficit bug if it does not. Further, if I can identify a particular extension causing the issue, then LO should really want to know about that and remove it from the public extensions repo. Regards.
Version: 7.1.5.2 (x64) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Un-installed then re-installed extensions in use with no apparent effect on color picker. None of the extensions I use would be expected to have a color picker palette component in any case. Regards.
(In reply to R. Bingham from comment #7) > (In reply to Roman Kuznetsov from comment #6) > > So strange. Can you reset your user profile using menu item Help-Restart in > > Safe Mode? > > Restart in Safe Mode (no options selected) does restore the color picker I/F > working as expected but of course without any palatte entries that may have > been created by extensions. So then likely some extension > install/update/uninstall horked the the color picker widget config in the > user profile. Assuming this is the case, then 2 courses of recovery: Then it is some unknown "corruption" of the user profile. You may zip up the profile and attach it, if you want, but I'm not sure if anyone can use it to troubleshoot. https://wiki.documentfoundation.org/UserProfile