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.

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.

*** Bug 91045 has been marked as a duplicate of this bug. ***

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.

(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.

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.

*** Bug 87831 has been marked as a duplicate of this bug. ***

*** Bug 104619 has been marked as a duplicate of this bug. ***

*** Bug 105442 has been marked as a duplicate of this bug. ***

MSI should be set to reuse existing Lo shortcuts, instead of deleting them and create new ones.

Adding Andras Timar, expert in Windows installer.

Three years later, this annoyance goes on.
Checked on the latest stable version 5.2.6.2

*** Bug 108699 has been marked as a duplicate of this bug. ***

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.

Yes, still seeing this on 5.4 rc2

*** Bug 109998 has been marked as a duplicate of this bug. ***

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.

The issue seems to generate some interest, let's set prio to medium for now.

(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.

*** Bug 114473 has been marked as a duplicate of this bug. ***

(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.

*** Bug 115961 has been marked as a duplicate of this bug. ***

*** Bug 117035 has been marked as a duplicate of this bug. ***

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.

(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

(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.

(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.

*** Bug 117996 has been marked as a duplicate of this bug. ***

(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.

*** Bug 119215 has been marked as a duplicate of this bug. ***

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.

*** Bug 124745 has been marked as a duplicate of this bug. ***

*** Bug 126174 has been marked as a duplicate of this bug. ***

*** Bug 127760 has been marked as a duplicate of this bug. ***

*** Bug 127140 has been marked as a duplicate of this bug. ***

*** Bug 127760 has been marked as a duplicate of this bug. ***

*** Bug 129246 has been marked as a duplicate of this bug. ***

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)

*** Bug 129577 has been marked as a duplicate of this bug. ***

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/

Nice try biel_m. However, serious manipulation of the registry on each update occasion has already been shunned (Comment 26).

*** Bug 137616 has been marked as a duplicate of this bug. ***

(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.

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.

However, doing this every time I want to update LO to the latest version is time consuming and tedious.

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\...

"AppData\Roaming\Microsoft\..." and
%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations
are the same.

The so-called environmental variable "%appdata%" equals "C:\Users\Username\AppData\Roaming"

(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.

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

Same as yours.

(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.

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.

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.

(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).

(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?

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.

*** Bug 141819 has been marked as a duplicate of this bug. ***

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.

(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.

(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.

*** Bug 146239 has been marked as a duplicate of this bug. ***

*** Bug 146424 has been marked as a duplicate of this bug. ***

*** Bug 147065 has been marked as a duplicate of this bug. ***

Note that https://gerrit.libreoffice.org/c/core/+/131540 has added an API for creation of custom jumplists. No idea how can we use that to handle this problem, though.

Same issue here on win11/LO7.3
For this bug I refuse to update LO more than once a year as it takes a few weeks to pin often used files again, which is annoying.
As I understand it, this could be a bigger security issue than it seems at first sight as it keeps many from updating. And thus keeping older versions running where they probably should not. It is also very inconvenient when it is introduced to school computers, as many teachers will run back to MS Word the moment their taskbar icons start disappearing.

As I see it, this is not merely a "bug", but simply bad programming. I am frequently up-dating software, but very few apps need the existing version to be uninstalled before installing the updated version. Most merely update the relevant DLL files into the existing software. This particular issue is limited to the part of the software dealing with the formation of the taskbar listings. Therefore, it seems to me that only that portion of the code needs to be replaced, leaving everything else untouched.

Dealing with updates in that fashion would not only leave everything else as it was, but the updating process would take much less time to complete, with minimal impact on the registry, which cannot be a bad thing.

(In reply to John Page from comment #70)
> As I see it, this is not merely a "bug", but simply bad programming. I am
> frequently up-dating software, but very few apps need the existing version
> to be uninstalled before installing the updated version. Most merely update
> the relevant DLL files into the existing software. This particular issue is
> limited to the part of the software dealing with the formation of the
> taskbar listings. Therefore, it seems to me that only that portion of the
> code needs to be replaced, leaving everything else untouched.
> 
> Dealing with updates in that fashion would not only leave everything else as
> it was, but the updating process would take much less time to complete, with
> minimal impact on the registry, which cannot be a bad thing.

That is generically know as incremental updating. See bug 68274, or the general tracking meta bug 113339.  And, retaining Windows JumpLists inside user os profiles is native code.

Specific Windows packaging might address situation for os/DE registered JumpLists -- but project cross-platform already retains our MRU history in our per-user profile.  The Windows specific bug has received attention, and while we've been able to retain between minor incremental builds the rub comes with major version updates. 

There might be a solution, but it remains a minor issue (though affecting all Windows users at version update).

*** Bug 151201 has been marked as a duplicate of this bug. ***

*** Bug 153337 has been marked as a duplicate of this bug. ***

In the context of Mike's correct remarks, I would like to extend this bug with a part of my bug 153337, so that I can mark it as duplicate.

In my bug I addressed on the one hand the problem of icons in the taskbar discussed here, however I also addressed a similar problem in the start menu :

If I pin links to several LibreOffice programs in the Start menu, e.g. LibreOffice, LibreOffice Writer and LibreOffice Calc in exactly this order, then these are still present and active after an update in contrast to the icons in the TaskBar, but the order is swapped, e.g. LibreOffice Calc, LibreOffice and LibreOffice Writer. So after each update I have to fix the icons in the taskbar and also the order of the icons in the start menu. This is not a big issue for single devices, but extremely annoying if you have to do it several hundred times a year.

Since I do, among other things, the installation and maintenance of far over a hundred computers, almost all of which have LibreOffice installed, resolving these two issues would be a huge time saver for me.

However, I would like to avoid workarounds that work via registry and file system tinkering in pre- and post-installation scripts. This can be done on a single private computer, but in a professional environment and on a larger scale, this is associated with too many risks.

In this context, I am always amazed why the installation of Libreoffice takes so long. It takes about as long as the complete reinstallation of the operating system...

*** Bug 154891 has been marked as a duplicate of this bug. ***

*** Bug 143928 has been marked as a duplicate of this bug. ***

It's approaching 10 years since this was reported. So, I wonder: Are there any Windows users among LO coders?

(In reply to Kumāra from comment #80)

I am.
But I wonder why you ask? Does it make *any* difference?
Because some of the questions that *make sense* are: "Are there coders among interested people here?", or "How can we interested people hire someone to implement this?" (not me, I'm not interested, even if you crowd-fund).

(In reply to Mike Kaganski from comment #81)
> (In reply to Kumāra from comment #80)
> 
> I am.
> But I wonder why you ask? Does it make *any* difference?

Yes. I mean, don't you feel bothered by this bug?

(In reply to Kumāra from comment #82)

I felt, enough to make an attempt mentioned in but 117492 comment 7, which would also address this one. My volunteer energy on this topic was insufficient.

Here's the correct link referenced above: https://bugs.documentfoundation.org/show_bug.cgi?id=117492#c7

Still waiting for an angel, with enough volunteer energy.

*** Bug 143968 has been marked as a duplicate of this bug. ***

this is a typical Windows shell problem... which M$ should fix (for a long time), but off course, they never will, as they don't care about software that does not bring in money.

so I guess it could maybe solved by totally changing the way OO or libreOffice updates...

instead of uninstalling the current version and then installing the new one, it could be implemented in the future versions to just upgrade the changed files in the existing install directory.

in that way the Taskbar lnk will just stay how it was, including the pinned documents to it. as it is not directly aware of a changed shortcut...

a lot of other windows software does its updates that way, to get around that retarded windows shell problem.

just a proposal..?

--
Kleajmp

*** Bug 160027 has been marked as a duplicate of this bug. ***