Bug 76131 - Existing pinned icon on Win7/8 is taskbar invalid after re-installation/update
Summary: Existing pinned icon on Win7/8 is taskbar invalid after re-installation/update
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
4.2.2.1 release
Hardware: Other Windows (All)
: highest minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 87831 91045 104619 105442 108699 109998 114473 115961 117035 117996 119215 124745 126174 127140 127760 129246 129577 137616 141819 (view as bug list)
Depends on:
Blocks: Desktop-Integration Installer-Windows
  Show dependency treegraph
 
Reported: 2014-03-13 17:41 UTC by Jared
Modified: 2021-11-23 01:08 UTC (History)
35 users (show)

See Also:
Crash report or crash signature:


Attachments
PM exchange regards the Windows custom AppID (e.g. AppUserID) we are using in the LibreOffice core (4.27 KB, text/plain)
2020-11-26 21:01 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jared 2014-03-13 17:41:17 UTC
After performing update the existing LibreOffice general icon which is pinned to the taskbar is invalid and must be deleted.  Then a new pin needs to be made from the refreshed program shortcuts.
Most native-Windows installations allow for programs to remain functioning as previously pinned to the taskbar, unless a directory change is performed during the update.
After re-installing/updating LibreOffice, the LO-specific icon is gone, and a generic white icon exists at the location of the pinned program.  This needs to be removed by the user and the newly installed app re-pinned. (That's a lot of additional user-required steps)
Comment 1 rj_libreoffice 2014-04-15 20:35:24 UTC
I am also experiencing this problem. I just saw it with the installation of LibreOffice 4.2.3.3.

I am running Windows 8.1 and have LibreOffice Calc pinned to my taskbar since I use it almost daily. I also have a spreadsheet that I use regularly pinned on the jump list. Whenever I install a new version of LibreOffice, the Calc shortcut does not work, even though the path to Calc is still valid. So then I have to unpin Calc from my taskbar, repin it, and repin my spreadsheet to the jump list, which is annoying.

I suspect that the reason for this is because the MSI installer first uninstalls the old version, which includes removing LibreOffice shortcuts. Somehow this must mess up the shortcut on the taskbar.
Comment 2 Lukas 2015-01-04 12:40:51 UTC
I see the same problem and want to emphasize statement of rj_libreoffice.
It would be very helpful if pinned documents are kept while update installation.
Comment 3 Buovjaga 2015-05-07 12:09:43 UTC
*** Bug 91045 has been marked as a duplicate of this bug. ***
Comment 4 gioni 2015-11-10 07:29:21 UTC
I see the same problem too since I begun to use it 7-8 years ago.
It would be very helpful if pinned documents are kept while update installation.
Comment 5 Kumāra 2016-02-17 07:07:02 UTC
(In reply to rj_libreoffice from comment #1)
> I suspect that the reason for this is because the MSI installer first
> uninstalls the old version, which includes removing LibreOffice shortcuts.

I believe so too. Since most applications (actually all others that I know) are able to retain the jumplist, I believe there shoudn't be any hindrance for LO to do the same. I do suggesting testing with having the MSI installer not remove existing LO shortcuts.
Comment 6 Kumāra 2016-02-17 07:08:39 UTC
I'd like to add that I rely on the jumplists a lot too and it's quite annoying to have to rebuild them each time I upgrade LO.
Comment 7 Kumāra 2016-12-09 10:11:55 UTC
*** Bug 87831 has been marked as a duplicate of this bug. ***
Comment 8 Buovjaga 2016-12-14 14:08:34 UTC
*** Bug 104619 has been marked as a duplicate of this bug. ***
Comment 9 Buovjaga 2017-01-24 07:46:21 UTC
*** Bug 105442 has been marked as a duplicate of this bug. ***
Comment 10 Kumāra 2017-02-07 06:45:53 UTC
MSI should be set to reuse existing Lo shortcuts, instead of deleting them and create new ones.

Adding Andras Timar, expert in Windows installer.
Comment 11 Chris 2017-03-25 09:40:09 UTC
Three years later, this annoyance goes on.
Checked on the latest stable version 5.2.6.2
Comment 12 Xisco Faulí 2017-06-22 23:49:57 UTC
*** Bug 108699 has been marked as a duplicate of this bug. ***
Comment 13 Lynne Connolly 2017-06-23 00:15:39 UTC
I filed a new bug report which is a duplicate of this one. It's super annoying. I have a long list of items pinned to my Writer jumplist, and with every update I have to add them all over again.
Comment 14 Jared 2017-07-26 16:10:13 UTC
Yes, still seeing this on 5.4 rc2
Comment 15 V Stuart Foote 2017-07-29 13:19:54 UTC
*** Bug 109998 has been marked as a duplicate of this bug. ***
Comment 16 Kumāra 2017-10-09 08:41:22 UTC
I notice that this is set to Low for importance. I'd like to challenge that.

Although this bug does not *normally* disrupt work, it does (for people who uses Windows's pinning feature) every time one upgrades LO. Whenever that happens, it takes some time to rebuild the pinned items.

This bug deters me from upgrading. But after some time, I forget. Then being interested in some new features, I decide to upgrade, then I regret.

Now I notice that I'm reluctant to upgrade just because of this bug.

My request: Please set this annoying, upgrade-deterring bug to a higher importance.
Comment 17 Aron Budea 2017-10-10 08:39:36 UTC
The issue seems to generate some interest, let's set prio to medium for now.
Comment 18 Jared 2017-10-12 17:40:37 UTC
(In reply to Kumāra from comment #16)
> I notice that this is set to Low for importance. I'd like to challenge that.
> 
> Although this bug does not *normally* disrupt work, it does (for people who
> uses Windows's pinning feature) every time one upgrades LO. Whenever that
> happens, it takes some time to rebuild the pinned items.
> 
> This bug deters me from upgrading. But after some time, I forget. Then being
> interested in some new features, I decide to upgrade, then I regret.
> 
> Now I notice that I'm reluctant to upgrade just because of this bug.
> 
> My request: Please set this annoying, upgrade-deterring bug to a higher
> importance.

I'm also very interested to see this feature/issue resolved. I feel it makes for a much better, less obtrusive experience for users.
Comment 19 Timur 2017-12-14 18:13:05 UTC
*** Bug 114473 has been marked as a duplicate of this bug. ***
Comment 20 tomaskeb 2018-02-10 08:06:43 UTC Comment hidden (no-value)
Comment 21 Kumāra 2018-02-12 07:39:45 UTC
(In reply to tomaskeb from comment #20)
> This bug makes me hate upgrading… its repair should be trivial, shouldn’t
> it? So why is it still there, over 2 major versions?

Oh, thank you very much for reminding me. I had thought of upgrading when Bug 108580 gets resolved. Now, I need to remember that I shouldn't until this gets resolved too. Now, happy to live with 5.2.5.1 (x64). Yep, I've not been upgrading for some while.
Comment 22 V Stuart Foote 2018-02-23 14:53:29 UTC
*** Bug 115961 has been marked as a duplicate of this bug. ***
Comment 23 Buovjaga 2018-04-23 07:46:04 UTC
*** Bug 117035 has been marked as a duplicate of this bug. ***
Comment 24 John Page 2018-05-17 21:19:54 UTC
We're now halfway through May 2018, and this bug is still there on the latest version - 6.0.4.2. I'm using Windows 10x64, and notice that the updates take just as long to install as the original program did. Why can't they be limited to ony the changes since the previous version, and keeping the user's preferences etc? While installing I'm forced to go through the options list every time, instead of the previous options selection being re-used, like most other apps.
Comment 25 V Stuart Foote 2018-05-18 05:28:05 UTC
(In reply to John Page from comment #24)
> We're now halfway through May 2018, and this bug is still there on the
> latest version - 6.0.4.2. 

And? 

There is little dev interest in implementing this Windows installer code to tweak per user migration of Windows 7 Jump List entries (Start menu or Task bar). Especially as Windows 7 Jump Lists have been deprecated by Microsoft [1]. Even less appealing given the divergence of Microsoft's VS 2010 implementation in .NET and UWP flavors. 

Otherwise, LibreOffice's profile held history of recently used documents already migrates with the profile when upgrading and is supported in the Start Center GUI or menu list.

> I'm using Windows 10x64, and notice that the
> updates take just as long to install as the original program did. Why can't
> they be limited to ony the changes since the previous version, and keeping
> the user's preferences etc? While installing I'm forced to go through the
> options list every time, instead of the previous options selection being
> re-used, like most other apps.

Maybe. See bug 68247 (and meta bug 54242) for progress on incremental updates (Linux & Windows), 

@Andras, Mike K.- while thinking about Windows installer rework for bug 117492--a "straw man" to ponder: is it worth the effort to add custom object logic to the installer--condition Installed and Patch--for an option to move / restore the Windows 7 Jump List items--outside (with our LO cache, logs?) our maybe inside our User profile? 

To be recorded back to Windows registry per newly (re)registered AppUserModelID and regenerating the Jump lists for items held per user now in:
"/User/<userid>/appData/Roaming/Microsoft/Windows/Recent Items"
"/User/<userid>/appData/Roaming/Microsoft/Internet Explorer/Quick Launch/User Pinned/Taskbar"

Or are we stuck as now that during the uninstalling we clobber the linkages and the pinned JumpLists are pruned?

Rather seems the later remains reasonable handling and this becomes a clear =>WONTFIX by attrition. That is maintain the current implementation, but not invest dev effort to making its migration per user profile more robust.

=-ref-=
https://msdn.microsoft.com/en-us/library/system.windows.shell.jumplist(v=vs.100).aspx
Comment 26 Mike Kaganski 2018-05-18 06:05:18 UTC
(In reply to John Page from comment #24)
> I'm using Windows 10x64, and notice that the
> updates take just as long to install as the original program did. Why
> can't they be limited to ony the changes since the previous version,

This part may be fixed by implementing the proposal in bug 117492.

> and keeping
> the user's preferences etc? While installing I'm forced to go through the
> options list every time, instead of the previous options selection being
> re-used, like most other apps.

And this part of question is simply false. Current installer *does* read and keep the user preferences; it must reinstall the same components you've installed last time with previous version's installer. The process is that it reads the installed components state first; then shows you the UI, where the installed component state is honoured; then uninstall the previous installation fully; then installs the new version with those components that were either recorded from previous installation, or changed by user in the UI.

(In reply to V Stuart Foote from comment #25)

I don't know if there would be regressions implementing the said bug 117492 (of course, our famous last words are "I'm sure it will work!"); but *possibly* it could also fix this problem without any additional logic (because in that case, no uninstallation would take place, only removal of replaced/obsoleted files) - but I don't actually know enough on that matter. Failing that, the proper way would be implementing the jump lists API in our shell extension / program, and thus keep the data in the user profile (thus having no troubles with upgrades that don't affect it). Direct registry manipulation here isn't the most attractive way.
Comment 27 Kumāra 2018-05-18 07:08:35 UTC
(In reply to Mike Kaganski from comment #26)

"no uninstallation would take place, only removal of replaced/obsoleted files"
This sounds like a very good idea. You have my vote on this.
Comment 28 Kumāra 2018-05-18 09:38:48 UTC Comment hidden (obsolete)
Comment 29 V Stuart Foote 2018-06-04 19:45:40 UTC
*** Bug 117996 has been marked as a duplicate of this bug. ***
Comment 30 Kumāra 2018-07-30 04:31:03 UTC
(In reply to Kumāra from comment #28)
> (In reply to Mike Kaganski from comment #26)
> > I don't know if there would be regressions implementing the said bug 117492
> > (of course, our famous last words are "I'm sure it will work!"); but
> > *possibly* it could also fix this problem without any additional logic
> > (because in that case, no uninstallation would take place, only removal of
> > replaced/obsoleted files) - but I don't actually know enough on that matter.
> 
> I suggest affected users head over to there (bug 117492) to give your
> comments.

I've just volunteered to test. If more people can test, we can get this done faster and better. This is a communal product. Since all of us have benefitted, we should also contribute. Please head over to bug 117492.
Comment 31 Buovjaga 2018-09-03 18:39:19 UTC
*** Bug 119215 has been marked as a duplicate of this bug. ***
Comment 32 Kumāra 2019-02-08 02:54:16 UTC
As mentioned at bug 117492, Mike Kaganski has given up on the more elaborate fix:
> The technical problem here is clear, and it is solvable, but it needs more
> work than I'm able to invest ATM; so leaving this here in case someone wants
> to jump-in.

So, I think for our benefit, better to just work on the original idea, that is simply to have the MSI installer *not* remove LibreOffice shortcuts (while uninstalling the old version).

Can someone try this? I'm happy to test.
Comment 33 Mike Kaganski 2019-04-15 09:02:30 UTC
*** Bug 124745 has been marked as a duplicate of this bug. ***
Comment 34 Mike Kaganski 2019-07-01 10:25:48 UTC
*** Bug 126174 has been marked as a duplicate of this bug. ***
Comment 35 Mike Kaganski 2019-09-25 15:19:12 UTC
*** Bug 127760 has been marked as a duplicate of this bug. ***
Comment 36 V Stuart Foote 2019-09-25 16:08:52 UTC
*** Bug 127140 has been marked as a duplicate of this bug. ***
Comment 37 Mike Kaganski 2019-09-26 09:03:58 UTC
*** Bug 127760 has been marked as a duplicate of this bug. ***
Comment 38 V Stuart Foote 2019-12-07 01:05:55 UTC
*** Bug 129246 has been marked as a duplicate of this bug. ***
Comment 39 VistaMail1 2019-12-07 11:21:13 UTC
May I change this to "normal"? 28 persons are following it.
And the suggestion of the workaround seems quite easy to do. It shall be just a checkbox on installion to "NOT" delete (see comments above)
Comment 40 V Stuart Foote 2019-12-23 14:51:03 UTC
*** Bug 129577 has been marked as a duplicate of this bug. ***
Comment 41 MikeB 2019-12-23 16:16:33 UTC Comment hidden (me-too)
Comment 42 beil m 2020-06-13 20:14:02 UTC
Looking thru the comments, looks like this has been mentioned before for earlier versions of windoze.  This comment is for win10.
I place icons for each program (write, calc, draw) on the taskbar.  This allows me to pin documents used often to the specific program.
When performing an upgrade, old version is removed, new version is installed. When performing an upgrade, not only are the taskbar icons removed, docs pinned to the application icons are lost also.  
This causes two problems:  1) have to recreate the application icons on the taskbar (not a huge problem)  2) Need to re-pin docs to icon which they were associated.  This is a PITA (mostly because I don't remember all docs that were pinned).
Suggestion: Until this icon removing problem is resolved, to helps speed up the restore process, it would be helpful for the upgrade to spit out in a text file somewhere, listing which files were pinned to which icons.

Problem:  Looks like files pinned to an icon are stored in the registry (of course they are).  Perhaps this Pinned Taskbar backup/restore procedure could be applied when upgrading.
https://helpdeskgeek.com/how-to/backup-and-restore-your-pinned-taskbar-items-in-windows/
Comment 43 John Page 2020-06-13 22:34:19 UTC
Nice try biel_m. However, serious manipulation of the registry on each update occasion has already been shunned (Comment 26).
Comment 44 Mike Kaganski 2020-10-20 10:58:50 UTC
*** Bug 137616 has been marked as a duplicate of this bug. ***
Comment 45 Kumāra 2020-11-23 08:23:02 UTC
(In reply to MikeB from comment #41)
> VistaMail1@web.de has asked for this to be "normal".  
> 
> I concur.  With so many users reporting this and the fix being reported as
> relatively easy, I'd really like to see this minor but annoying bug fixed.

Yes, I think “minor” is most appropriate.
Comment 46 Jones 2020-11-23 10:30:19 UTC
The documents that users can pin to the JumpLists of the Taskbar or Start Menu icons are stored in this folder/path:

"%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations"

Inside this folder there is a file for every program that has such pinned items, either manually pinned by the user and/or automatically pinned by Windows. (If I am not mistaken, the individual file name is derived from the installation path of the software and stored as some kind of "hash" value. Therefore those weird names.)

In my case, the pinned items for LO Writer are stored in the file "d38a3ea7ec79fbed.automaticDestinations-ms", the pinned items for Calc are stored in the file "83dd64e7fa560bd5.automaticDestinations-ms".

You can easily backup those files before doing a re-installation or update installation of LO. After the installation has finished, just copy the filed back to it's location and your pinned items in the JumpLists are back.
Comment 47 Jones 2020-11-23 10:34:23 UTC
However, doing this every time I want to update LO to the latest version is time consuming and tedious.
Comment 48 John Page 2020-11-23 11:52:24 UTC
Right: so the easiest way to fix this bug is to NOT delete the file in "Automatic Destinations" when the previous version is removed.

Better still would be NOT remove the previous version, but simply update on top of the previous version. As most of the elements of the previous version remain the same it seems to me that it's sheer folly to remove everything each time an update is installed.
BTW, the location of the "AutomaticDestinations" folder in Windows 10 is under AppData\Roaming\Microsoft\...
Comment 49 Jones 2020-11-23 13:29:50 UTC
"AppData\Roaming\Microsoft\..." and
%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations
are the same.

The so-called environmental variable "%appdata%" equals "C:\Users\Username\AppData\Roaming"
Comment 50 V Stuart Foote 2020-11-23 15:22:16 UTC
(In reply to Riban from comment #46)
> You can easily backup those files before doing a re-installation or update
> installation of LO. After the installation has finished, just copy the filed
> back to it's location and your pinned items in the JumpLists are back.

You need both the pinned module entries (just normal Windows shell Shortcuts) in:

C:\Users\<userID>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar


And the specific AUTOMATICDESTINATION datafile held in the 'Recent items' library:
C:\Users\<userID>\AppData\Roaming\Microsoft\Windows\Recent

These are the AppIDs specific for LO 7.0

83dd64e7fa560bd5.automaticDestinations-ms -- Calc 7.0
d38a3ea7ec79fbed.automaticDestinations-ms -- Writer 7.0
ecd1a5e2c3af9c46.automaticDestinations-ms -- Impress 7.0
f6fd5d99e2b6e178.automaticDestinations-ms -- Draw 7.0
7c2916afd6f116a6.automaticDestinations-ms -- Base 7.0
26753c97ea000ecd.automaticDestinations-ms -- Math 7.0

Unfortunately they will change at each major release, so for 7.1 releases they will get new AppIDs when the GUID for LibreOffice changes. Believe the content remains valide/reusable, but the AppIDs/names have to be changed to restore.
Comment 51 Jones 2020-11-23 15:33:24 UTC
I don't think that the AppIDs you provided are specific for LO 7.0 and that they change (with every major version).

Currently I have LO version 6.4.7.2 (x64) installed and the AppIDs are:

Calc: 83dd64e7fa560bd5.automaticDestinations-ms
Writer: d38a3ea7ec79fbed.automaticDestinations-ms
Comment 52 Jones 2020-11-23 15:34:16 UTC
Same as yours.
Comment 53 V Stuart Foote 2020-11-23 16:33:51 UTC
(In reply to Riban from comment #51)
> I don't think that the AppIDs you provided are specific for LO 7.0 and that
> they change (with every major version).
> 
> Currently I have LO version 6.4.7.2 (x64) installed and the AppIDs are:
> 
> Calc: 83dd64e7fa560bd5.automaticDestinations-ms
> Writer: d38a3ea7ec79fbed.automaticDestinations-ms

Hmm, that may be correct. The AppIDs recorded as AUTOMATIC-DESTINATIONS-ms reportedly calculated against install path and bitness of the executable [1].

Meaning the AppIDs should remain unchanged LO release to release as we do not change install path, i.e. the module launchers are always found at "C:\Program Files\LibreOffice\program" for a default install.

=-ref-=
[1] https://www.hexacorn.com/blog/2013/04/30/jumplists-file-names-and-appid-calculator/  I tried the provided appid_calc.pl but I don't get AppID matches running on a Windows 10 64-bit (2004) en-US build -- meaning either the polynomial or the AppID algorithim has changed, but premise as non-CLSID/GUID based seems valid.
Comment 54 Kumāra 2020-11-24 01:17:17 UTC
I(In reply to Riban from comment #46)
> The documents that users can pin to the JumpLists of the Taskbar or Start
> Menu icons are stored in this folder/path:
> 
> "%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations"
。。。
 
> You can easily backup those files before doing a re-installation or update
> installation of LO. After the installation has finished, just copy the filed
> back to it's location and your pinned items in the JumpLists are back.

I think I've tried this before and it didn't work. Maybe I missed something.
Comment 55 Jones 2020-11-24 14:16:56 UTC Comment hidden (me-too)
Comment 56 jbstory 2020-11-24 17:34:52 UTC
I don't have either an AutomaticDestinations or a CustomDestinations folder. I HAD a CustomDestinations but it disappeared after I installed the update and I've been unable to recreate it (I backed up the old one to a thumb drive). I manually recreated my Calc jumplist and it works just fine, as do the rest of my jumplists that stay put after updates, but there's no Destinations folder. Using Win 10 2004 Home (64 bit) and LO 6.4.7.2 x64.
Comment 57 V Stuart Foote 2020-11-24 17:56:51 UTC
(In reply to jbstory from comment #56)
> I don't have either an AutomaticDestinations or a CustomDestinations folder.
> I HAD a CustomDestinations but it disappeared after I installed the update
> and I've been unable to recreate it (I backed up the old one to a thumb
> drive). I manually recreated my Calc jumplist and it works just fine, as do
> the rest of my jumplists that stay put after updates, but there's no
> Destinations folder. Using Win 10 2004 Home (64 bit) and LO 6.4.7.2 x64.

The are "special" Windows shell folders receiving library handling.  To access in Windows Explorer you need to enter the full path exactly in the navigation bar, E.g.

C:\Users\<userID>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations

the same for the CustomDestinations folder (where some programs record a specific AppID).
Comment 58 V Stuart Foote 2020-11-26 19:44:36 UTC
(In reply to V Stuart Foote from comment #53)
 
> Hmm, that may be correct. The AppIDs recorded as AUTOMATIC-DESTINATIONS-ms
> reportedly calculated against install path and bitness of the executable [1].
...

> =-ref-=
> [1]
> https://www.hexacorn.com/blog/2013/04/30/jumplists-file-names-and-appid-
> calculator/  I tried the provided appid_calc.pl but I don't get AppID
> matches running on a Windows 10 64-bit (2004) en-US build -- meaning either
> the polynomial or the AppID algorithim has changed, but premise as
> non-CLSID/GUID based seems valid.

OK spent some time with HEXACORN dev Adam, their appid_calc.pl script needed a tweak, but turns out we are not auto-generating the AUTOMATIC-DESTINATION-ms appIDs. Instead for work on bug 35785 we are creating a custom AppIDs (UserAppID) string for each module that are being recorded into the Windows registry. Looking at bug 35785 these remain non-advertised, which if IUUC means the MS Installer packaging must remove and recreate--clobbering the content in the AutomaticDestination folder.

@Mike K., Fredric S, * -- would a change to "published" allow persistence in the MSI upgrades?
Comment 59 V Stuart Foote 2020-11-26 21:01:19 UTC
Created attachment 167601 [details]
PM exchange regards the Windows custom AppID (e.g. AppUserID) we are using in the LibreOffice core

see the ref commit for the final form of the AppUserID per module

https://cgit.freedesktop.org/libreoffice/core/commit/?id=6205c58e262e9b82e815855199de462775fcd35b

That is:
TheDocumentFoundation.LibreOffice.Base
TheDocumentFoundation.LibreOffice.Calc
TheDocumentFoundation.LibreOffice.Draw
TheDocumentFoundation.LibreOffice.Impress
TheDocumentFoundation.LibreOffice.Startcenter
TheDocumentFoundation.LibreOffice.Writer
TheDocumentFoundation.LibreOffice.Math

rather than their .exe launchers,  are parsed to generate the AutomaticDestination-ms AppID.
Comment 60 L Duperval 2021-05-04 14:31:22 UTC
*** Bug 141819 has been marked as a duplicate of this bug. ***
Comment 61 AM 2021-11-21 11:24:31 UTC
The issue seems still be existing in Window 10 and LO 7.2.2.2 (x64) and it is annoying. I'm trying to avoid installing LO updates for years now because of this issue. Each time hoping that it is finally working now.
Comment 62 VistaMail1 2021-11-22 10:41:00 UTC
Thank you for the information.
Same here: Because of the mess in my work, I avoid taking updates of LibreOffice.
Comment 63 VistaMail1 2021-11-22 15:03:03 UTC
(In reply to VistaMail1 from comment #62)
> Thank you for the information.
> Same here: Because of the mess in my work, I avoid taking updates of
> LibreOffice.

and PS:
I do not understand the details, why this happens.
The only thing I know: Other software can be installed without this mess.
Comment 64 Kumāra 2021-11-23 01:08:05 UTC
(In reply to AM from comment #61)
> The issue seems still be existing in Window 10 and LO 7.2.2.2 (x64) and it
> is annoying. I'm trying to avoid installing LO updates for years now because
> of this issue. Each time hoping that it is finally working now.

You've come to the right place to know if it's fixed.

I've stopped updating sooner--since 6.0.4.2---because of this issue.