Bug 111338 - LibO will update the registrymodifications.xcu for every color chosen in the color picker (since LibO 5.3)
Summary: LibO will update the registrymodifications.xcu for every color chosen in the ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Hardware: All Windows (All)
: medium trivial
Assignee: Not Assigned
Keywords: bibisected, bisected
Depends on:
Blocks: Color-Picker-Widget Too-Much-File-Access
  Show dependency treegraph
Reported: 2017-08-04 12:03 UTC by Telesto
Modified: 2020-01-23 02:54 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-08-04 12:03:02 UTC
When a color is chosen in the color picker, a tmp file is written (since LibO5.3)

Steps to Reproduce:
1. Open Writer
2. Type something on the first row (and select it)
3. Open Process Monitor.
4. Set a filter PATH contains Data\settings\user\
5. Open the font color picker an choose a font color. 

Actual Results:  
A small temp file is written. The temp file is created in various cases. See bug 108655. However this one is introduced recently and LibO5.2 is working perfectly fine without.

Expected Results:
The temp write is probably not needed. So no Write at all

Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Build ID: 46b9d35ceaba80ce73fb0b4b5a87dbdf0a674628
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-08-02_23:46:51
Locale: nl-NL (nl_NL); Calc: CL

and in
Build ID: f4b7650ecd46e5404b35dccfb8b7d3b0a385d633
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2016-12-16_12:19:09
Locale: nl-NL (nl_NL); Calc: CL

but not in:
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: CL

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 tommy27 2017-08-04 14:07:40 UTC
is this temp file subsequently deleted or overwritten?
Comment 2 Telesto 2017-08-04 14:43:42 UTC
(In reply to tommy27 from comment #1)
> is this temp file subsequently deleted or overwritten?

I can be a bit more specific after looking more closely at the output. The change in the color picker initializes a registrymodifications.xcu update. The change is written into a *.tmp file, renamed to registrymodifications.xcu after a successful save. The process takes up +/- 1 millisecond
Comment 3 Telesto 2017-08-04 15:02:37 UTC
To be more precise, the registrymodifications.xcu update is related to two settings: RecentColor and RecentColorName

<item oor:path="/org.openoffice.Office.Common/UserColors"><prop oor:name="RecentColor" oor:op="fuse"><value>0</value></prop></item>

<item oor:path="/org.openoffice.Office.Common/UserColors"><prop oor:name="RecentColorName" oor:op="fuse"><value><it>Black</it></value></prop></item>
Comment 4 Telesto 2017-09-08 18:28:29 UTC
About the expected results, because it has a purpose seen in the light of comment 3:

Probably a (changeable) interval based save. 
1. Re-saving registrymodifications.xcu on every change seems to be a bit excessive to me (especially because of the increasing file size when using different applications within the LibO suite). It will end op writing around 400kb every time when touching the highlight or color button (for example; there are more cases)
2. Being smart an hold of saving until LibO closes isn't that ideal either. For example when LibO is crashing or for debugging purposes.
Comment 5 Xisco Faulí 2018-11-26 19:10:10 UTC
Hi Telesto,
is this issue still reproducible in master ?
Comment 6 Telesto 2018-11-27 15:49:25 UTC
Still the same
Build ID: d71ea82055a6a304493c7eaa90809a348e23784d
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-19_03:25:07
Locale: en-US (nl_NL); UI-Language: en-US
Calc: CL
Comment 7 Xisco Faulí 2019-05-30 11:16:13 UTC
Hi Telesto,
any chance this could be bisected ?
Comment 8 Xisco Faulí 2019-07-05 10:17:58 UTC
(In reply to Xisco Faulí from comment #7)
> Hi Telesto,
> any chance this could be bisected ?

ping ?
Comment 9 Telesto 2019-07-05 12:31:28 UTC
Not sure if there is much to gain from it.. It's more a global design problem I guess.. The xcu is immediately updated on every change (floating dialogs, colors, window position etc). As such acceptable (but not ideal) if the xcu isn't to large. However this isn't the case. A xcu size of 2-4 MB isn't to exceptional causing a crazy amount of disk activity storing mostly trivial things

Lazy writing of xcu would be a solution. So storing a some intervals. Release build only of course as I might be problematic for debugging.
Another solution would be splitting settings to different xcu's but half-house solution; probably not desired anyway (backward compatibility ) 

It needs a Dev Evaluation IMHO
Comment 10 Xisco Faulí 2020-01-20 17:16:44 UTC
anyway, a bisection would be really helpful here
Comment 11 Telesto 2020-01-22 21:50:02 UTC
Bisected to:
author	Rishabh Kumar <kris.kr296@gmail.com>	2016-07-29 18:39:46 +0530
committer	Rishabh Kumar <kris.kr296@yahoo.in>	2016-07-29 14:52:56 +0000
commit	7f262a41017685709c288b57c8f03244e8c6149e (patch)
tree	130677ce67e64e47ab6341fa59a9ecac8fae2b63
parent	bb01247f71a46fb7cae18b51516096adfd059bbc (diff)
[GSoC] Fix recent colors in color popup widget
Save recent colors in user configuration.