Open Bug 493503 (mac-icon) Opened 15 years ago Updated 2 years ago

App icon in macOS Dock is sometimes missing or wrong

Categories

(Firefox :: General, defect, P3)

Product:
Firefox
Component:
General
Platform:
x86
macOS
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox61 --- wontfix
firefox63 --- ?

People

(Reporter: faaborg, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

Patch
2.64 KB, patch
spohl
: review+
Details | Diff | Splinter Review 
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)
Keywords: qawanted
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.
Keywords: qawanted
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!
Depends on: 600098
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) ?
Flags: needinfo?(robert.strong.bugs)
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.
Flags: needinfo?(robert.strong.bugs)
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).
(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.
Noting that this is still collecting duplicates.
status-firefox61: --- → wontfix
status-firefox63: --- → ?
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.
Attached patch Possible patch (obsolete) — — Splinter Review 
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.
Flags: needinfo?(spohl.mozilla.bugs)
(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.
Flags: needinfo?(spohl.mozilla.bugs)
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.
Attached patch Patch (obsolete) — — Splinter Review

After some back-and-forth in Apple's bug tracker it looks like the only good path forward here is to adjust the last modified date on the .app bundle itself. This will usually update the icon in Finder immediately. I have observed a slight delay once, but simply moving between folders in Finder fixed this issue.

The Dock is a slightly different problem. Changing the last modified date will trigger a refresh of the icon there as well. However, it is limited to when the user clicks on the icon to start the application. It will not refresh the icon when Firefox is restarted during an update. Clicking the icon while Firefox is running will also not update the icon.

Even though the fix isn't perfect for the Dock it will still be a good improvement over the status quo. Furthermore, we might have wanted to change the last modified date on the .app bundle during updates all along, since we did modify the app.

Attachment #9028502 - Attachment is obsolete: true
Attachment #9028502 - Flags: feedback?(robert.strong.bugs)
Attachment #9037411 - Flags: review?(robert.strong.bugs)
Attachment #9037411 - Flags: review?(mstange)
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+

(In reply to Markus Stange [:mstange] from comment #44)

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.

Thanks! Based on Apple's feedback I get the impression that the icon only refreshes if the user actually clicks on it. Let's hope that's not the case.

Comment on attachment 9037411 [details] [diff] [review]
Patch

I like this much better. Thank you!
Attachment #9037411 - Flags: review?(robert.strong.bugs) → review+
Attached patch Patch — — Splinter Review

Thanks for the quick reviews! I changed the NULLs to nil in this patch to be in line with the rest of the file, and our Cocoa code more generally. Carrying over r+.

Attachment #9037411 - Attachment is obsolete: true
Attachment #9037493 - Flags: 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

This approach brought back a memory of something similar we did a long time ago.

https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#2530

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #49)

This approach brought back a memory of something similar we did a long time ago.

https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#2530

Hmm, so we seem to be doing this already. And I just confirmed with an update to current release that it does indeed update the last modified date. I guess I should back out the change here. But this also means that we are back to square one in figuring out why these icons don't update properly...

I've wondered a few times if OS X sometimes checks the date of the Info.plist file or if the image still exists and whether changing the image filename and hence the entry in Info.plist file might fix this. I recall smichaud added code to the updater for a bundle that had to do with java iirc that touched the Info.plist of that bundle.

I should have realized that we already "touch" the bundle because app update actually tests this on OS X.

btw: oak should be in good shape to test different approaches hopefully sometime next week.

Since we're already touching the .app bundle during an update I don't currently have a suggestion on how to fix this bug. We are already doing what Apple suggested, so this bug just became a whole lot more mysterious.

Assignee: spohl.mozilla.bugs → nobody
Status: ASSIGNED → NEW
Priority: -- → P2

Two recent duplicates of this in 66 - one in 10.13 and one in 10.14.

Alias: mac-icon
Summary: Does OS X do any form of application icon caching? → Does OS X do any form of application icon caching? (wrong icon displayed in dock)
Summary: Does OS X do any form of application icon caching? (wrong icon displayed in dock) → App icon in macOS Dock is sometimes missing or wrong
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 10 duplicates.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dtownsend)
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: