Open Bug 493503 Opened 11 years ago Updated 5 months ago
Does OS X do any form of application icon caching?
Hey QA and OS X developers: I'm concerned that for OS X there might be some icon caching going on by the OS so that new app icons will not always appear if you have been using an older icon. I believe I personally encountered this with the software update icon, and the problem seemed to only correct itself after I drilled into the .app bundle to find the icon file to confirm that it was correct, causing it to render in the finder (and potentially update the OS icon cache?). Overall for something like software update this isn't necessarily a big deal, but since we are about to refresh the Firefox icon file I figured we should confirm if we have encountered icon caching in the past, and if so ask some OS X engineers if they know any tricks to make sure a new icon always appears. Software update might have also been an unusual case since the icon is stored in an app bundle that is inside of another app bundle, so in most cases the user will never view the icon in the Finder (assuming that actually has some relationship to caching).
It would be interesting to see if this is reproducible by: 1) Clean OS X install (never having had Firefox on it) 2) Install a FF build from early Jan 2009 (prior to the landing of bug 473337) 3) Update it to the current nightly (you'll still see the old updater icon in the Dock) 4) Wait 1 day 5) Update to the next current nightly (you should now see the new icon)
Sometimes icons can get cached, but (aiui) the cache is usually cleared on restart. It's entirely possible that some users will see the old update icon after installing 3.5 until after they restart. I'm not sure there's any way to force the icon cache to clear. Smokey might know better.
Yeah, the Finder definitely caches icons (application and document), and the cache can even become corrupt, so that you see a corrupted icon or even the icon for an entirely different application/document! I believe the Dock maintains a separate cache, but I'm not positive about that. A logout/login will fix a Finder cache issue (if you're impatient and can't log out, on the end-user side Cmd-I, click on the icon in Get Info, and Delete will fix things on a per-app/document basis, or you can trash the cache files). I haven't seen the issue on my Macs in a while, so I can't recall for sure if running a LaunchServices (re)register command and/or 'touch' on the bundle in question also works; I think they should, and you could in theory have the updater run that at the end of the update.
It's possible that this is also a symptom of the "stale bundle timestamp" issue described in bug 504397 comment 6.
Over in bug 493503 clegnitto suggests touching the binary after an update for a different reason, I wonder if that would help here too.
I ended up suggesting that in bug 504397 comment 19, too, and apparently made comment 4 here at the same time without noting my own suggestion :P
3 bonus points for anyone who knows what bug I _really_ meant in comment 5! Limited time only!
Mossop wins the prize -- bug 554997 comment 1.
(In reply to comment #8) > Mossop wins the prize -- bug 554997 comment 1. LegNeato you mean? btw: for one-off's like this the updater could be hardcoded to look for individual bundles and if they exist to touch them. Another option that won't make the updater do things other applications might not want is any Mac or Windows application can provide an app to launch after a successful update to perform post update work.
So, per bug 600098 comment #16 the dock icon isn't updated which would best be dealt with by a binary that is launched after update just like we do for Windows.
Looks like we could get away with touching the Info.plist after an update to get the dock icon to also update
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #11) > Looks like we could get away with touching the Info.plist after an update to > get the dock icon to also update We're updating icons again for 57. Who could implement something like this, given that it's still an issue based on nightly updates (see recent dupe) ?
Even on a complete update which sets the file times to the time of the update the icon didn't update for me. Creating a post update application that performs what is suggested in bug 554997 comment #2 is I suspect a more surefire way to accomplish this.
and any dev that can create OS X apps can create such an app. App update will launch the app based on the values in the updater.ini such as this for Windows. https://dxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/updater_append.ini If you'd like to try the touch method it can be done by updating the Info.plist file which can be done by using a new name for the icns file or a different change to the Info.plist file so partial updates modify the file. I don't think that is a worthwhile path since at least on my system that wasn't enough for the icon to change in the dock even though it changed on the bundle. https://dxr.mozilla.org/mozilla-central/source/browser/app/macbuild/Contents/Info.plist.in#169
I will try to prioritize this along with other bugs I'm working on due to numerous reports of users having broken app icons after updates (for example bug 1432609, bug 1392824).
Duplicate of this bug: 1432609
Is bug 1441007 a dup?
(In reply to Joe Hildebrand [:hildjj] (UTC-6) from comment #18) > Is bug 1441007 a dup? Looks like it to me, thanks for the heads-up.
(In reply to Joe Hildebrand [:hildjj] (UTC-6) from comment #18) > Is bug 1441007 a dup? The info about external displays is new and I'll keep that in mind when I finally get to this bug. Thanks!
My assumption is that the difference in display resolution mattered.
2 years ago
Duplicate of this bug: 1453466
Noting that this is still collecting duplicates.
There's apparently no updates to 61 since when I reported this issue back in July, so I'll just wait for Firefox 62 to be released, hoping that it will fix this bug.
(In reply to Eric M. Chen from comment #29) > There's apparently no updates to 61 since when I reported this issue back in > July, so I'll just wait for Firefox 62 to be released, hoping that it will > fix this bug. The issue is seemingly fixed in 61.0.2. The Firefox icon has restored on the Dock. Thank you!
(In reply to Eric M. Chen from comment #30) > (In reply to Eric M. Chen from comment #29) > > There's apparently no updates to 61 since when I reported this issue back in > > July, so I'll just wait for Firefox 62 to be released, hoping that it will > > fix this bug. > > The issue is seemingly fixed in 61.0.2. The Firefox icon has restored on the > Dock. Thank you! This is an intermittent issue that is more likely to occur when there were changes to the application icon. We should still address this as described in comment 14 and comment 15.
This patch makes the updater forcefully restart the Dock process. This has been the only reliable way that I could find to trigger a refresh of the icons. The approaches discussed in comment 14 and comment 15 had severe unintended consequences, such as replacing icons of system applications with the default application icon. The patch currently does this forceful restart of the Dock process for all updates (even if the application icon doesn't change) because it may be difficult to ensure that developers who change the application icon remember to add this call, even if it is executed as a post-update process. Robert, would you be able to test this patch with an update that actually changes the Firefox app icon? Or could you forward this request to someone who could? I'm 99% sure that this should work, but I haven't been able to test this end-to-end with an actual update. Thank you!
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Attachment #9028502 - Flags: feedback?(robert.strong.bugs)
What is the user experience when the dock process is killed? I would expect at the very least a flicker on the screen and possibly the disappearance of the dock. I'd also prefer not doing this for every update. We get bug reports when this happens and that should be enough for developers to know that they need turn it on. Also, by making it a post update process all they would have to do is add it to the updater.ini which would be simple enough. I'll see if I can get someone with a mac to test this out.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #33) > What is the user experience when the dock process is killed? I would expect > at the very least a flicker on the screen and possibly the disappearance of > the dock. The dock gently disappears to the bottom of the screen for a split-second and then restarts by sliding back into view. It's a rather smooth experience, not a flicker. > I'd also prefer not doing this for every update. We get bug reports when > this happens and that should be enough for developers to know that they need > turn it on. Don't these bug reports come in after we have already shipped the new icons? And to make matters worse, if the app icon changes for release, wouldn't we not hear about it until after it is already shipping? It might be that beta uses the same icons as release, so we might get lucky and hear about it during the beta cycle. But this would still leave dev edition. > Also, by making it a post update process all they would have to > do is add it to the updater.ini which would be simple enough. We don't allow the updater to start a post update executable that is outside of the .app bundle. So we wouldn't be able to specify /usr/bin/killall as the post update process directly. Writing an entirely new executable that just starts another process seems a bit heavy-handed. If we don't want to restart the dock with every update, could we introduce another key for the updater.ini and make the updater check for it? Something like `MacRefreshDockIcons=1`? If present, it would go ahead and restart the dock? > I'll see if I can get someone with a mac to test this out. Thank you!
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(robert.strong.bugs)
I can easily imagine a user performing an update, trying to click an icon in the dock, and then getting upset over the dock disappearing out from under them. At the very least this isn't a typical user experience on OS X and a user will be left confused as to why this is happening. When I've had experiences like this I've spent hours trying to find the culprit. The ones I've found have typically been a hack like this and I'm always very annoyed with the vendors that do these sort of things. I suspect that the current user experience for the clients that don't see the updated icon is that the icon is updated when the OS next restarts. I also suspect that the majority of users don't even notice this bug. Just to verify, restarting the OS has the same effect as killing the dock? Someone from UX should evaluate whether this experience is acceptable on every update or only when it is needed which is extremely rare or if it is acceptable at all given the above. I'm fairly certain these have always been caught soon after the icon change either on Nightly or on Dev Edition / Beta. Also, icon changes are extremely rare and it appears that not everyone experiences this bug hence doing this on every update is very much overkill. I am not a fan of killing an OS process... as I see it this is a sledgehammer approach to solving this. Are there any other applications that do this? I know legneato and Josh Aas had contacts at Apple that they would contact for issues like this. Can you or someone else reach out to Apple for guidance on this bug? Can you try replacing the icon manually to see if you can reproduce this bug? I suspect removing the icon and copying an icon with the same name into the bundle via a shell would suffice.
Flags: needinfo?(robert.strong.bugs) → needinfo?(spohl.mozilla.bugs)
I've experienced a missing icon when there have been no visible changes to it. That doesn't mean there wasn't something invisible going on though. As a user I find it frustrating because restarting Firefox doesn't fix it. It doesn't seem to be fixed until the next update is installed. I probably only restart my computer once a month though, maybe that would fix it faster? I'm also a Nightly user so probably experience this problem more than Release users. For a while it seemed to be happening quite frequently.
This bug is about the icon not being updated and the old icon displaying. What you have experienced sounds like an OS bug. spohl, have you experienced what Stephanie experienced in comment #5?
Bug 1460928 was closed as a duplicate of this one so I assumed it was addressing that problem, sorry.
These issues are all related, hence why bug 1460928 was closed as duplicate of this one. It has to do with an icon cache, used by the Dock process, that is out-of-date. While investigating this, there have been times that my icons would seem to work correctly only to disappear after the system came out of hibernation. I have reached out to Apple and will comment here if/when I hear back. Restarting the Dock process has been the only reliable way to force the icons to appear correctly so far.
Here is an example where killing the dock didn't fix the generic icon issue. https://discussions.apple.com/thread/8095249 I've also seen several threads that say additional steps are needed beyond just killing Dock such as removing the existing icon cache.
(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #40) > Here is an example where killing the dock didn't fix the generic icon issue. > https://discussions.apple.com/thread/8095249 > > I've also seen several threads that say additional steps are needed beyond > just killing Dock such as removing the existing icon cache. Yes, blowing away the cache itself has proven to be necessary for me too in some cases. But killing the Dock process was always necessary for the changes to take effect. Unfortunately, blowing away the cache has proven to be extremely tricky to get right. In some cases, blowing away the icon cache resulted in other, unrelated apps to lose their icons after the Dock process restarted. That didn't seem like a risk that we would want to take.
In summary, the relation is that both involve the Dock's icon cache. In one instance the old icon is displayed and in the other instance a generic icon is displayed. In some cases killing the Dock has not been reliable. In those cases deleting the cache itself has been necessary but this has resulted in the loss of icons for other apps.
Comment on attachment 9037411 [details] [diff] [review] Patch Review of attachment 9037411 [details] [diff] [review]: ----------------------------------------------------------------- Sounds good to me. About the restarting problem, bug 432520 makes me think that we need to change the method of restarting the browser anyways, to wait for the old process to quit completely before launching the new process, possibly through another helper process. Maybe that would make the Dock treat it as a true new start and trigger the icon check? Or is it really only doing the check if it's the *user* clicking the icon? Anyhow, something to try out later.
Attachment #9037411 - Flags: review?(mstange) → review+
Comment on attachment 9037411 [details] [diff] [review] Patch I like this much better. Thank you!
Attachment #9037411 - Flags: review?(robert.strong.bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/76786e51becf1fa3a23f0978791a80107acf2318 Bug 493503: Ensure that icons are refreshed in the macOS Dock and Finder after updates. r=mstange,rstrong
https://hg.mozilla.org/integration/mozilla-inbound/rev/2b951a7a429ed09e7b5717b04827408978daea01 Revert 76786e51becf (bug 493503) since this functionality is already in tree. r=me
Assignee: spohl.mozilla.bugs → nobody
Status: ASSIGNED → NEW
Priority: -- → P2
Duplicate of this bug: 1475991
You need to log in before you can comment on or make changes to this bug.