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)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 87831 91045 104619 105442 108699 109998 114473 115961 117035 117996 119215 124745 126174 (view as bug list)
Depends on:
Blocks: Desktop-Integration Installer-Windows
  Show dependency treegraph
 
Reported: 2014-03-13 17:41 UTC by Jared
Modified: 2019-07-01 10:25 UTC (History)
25 users (show)

See Also:
Crash report or crash signature:


Attachments

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