314794 - [Mac] After update the Finder doesn't display the correct version info on App Bundle

Status: RESOLVED DUPLICATE of bug 600098

(Toolkit :: Application Update, defect)

Description

[u49640]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/416.11 (KHTML, like Gecko) Safari/416.12
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

i just auto Updated from Beta2 to RC1 and noticed that my Finder still shows "1.4.1" as Firefox version info (see pic)

Reproducible: Always

Steps to Reproduce:

Comment 1

[u49640]

Attachment: The wrong Version info

(every other Version Strings are OK, but this one isnt)

Comment 2

[u49640]

strange... the Finder shows now the correct Version after a reboot.

i dont know if we should consider this a FF Bug or a Finder Bug. (is there something the Updater can do to force Finder to reload the Version String?)

(i'm not marking this invalid yet, because its still something other people could see and wonder if the Update went wrong)

Comment 3

[Josh Aas]

It is not uncommon for the Finder to delay updating information like versions. The Finder caches heavily, and is not perfect at invalidation. I doubt this is our bug.

Comment 4

[Josh Aas]

Note: Calling NSWorkspace's "- (void)noteFileSystemChanged:(NSString *)path" method on the app bundle or Info.plist might force it to update if anyone is interested in forcing an invalidation. Questionable if this is worth doing or not...

Comment 5

[Carsten Book [:Tomcat]]

Matthias: do you still see this problem with a latest release like the update from Firefox 2.0.0.3 -> Firefox 2.0.0.4 ?

Comment 6

[u49640]

haven't checked it since and i'm not on my mac so I cant check now.

Comment 7

[u49640]

just tried again:
happened on Thunderbird 1.5.0.9 -> 1.5.0.12
and with 2.0.0.0 -> 2.0.0.4

same thing with firefox 2.0.0.1 -> 2.0.0.4

Comment 8

[Robert Strong (they/them - no direct email)]

Comment #4 would be a good place to start if someone is interested in trying to fix this.

Comment 10

[Jamie Flournoy]

If this is a Finder bug, here's an idea for how to work around it in an installer... may not work, just a thought:

1) install the app in place as usual
2) mv the updated app to /Applications/Whatever_old.app
3) mkdir /Applications/Whatever.app
4) mv the contents of /Applications/Whatever_old.app into /Applications/Whatever.app
5) rm the now-empty /Applications/Whatever_old.app

In other words, maybe the Finder is caching the directory by inode rather than by pathname, and might wake up and notice the change if it thinks the directory is brand new.

Comment 11

[u49640]

I've tried it again with 3.0.6 -> 3.0.7 and saw the bug (10.5.6/Intel)

A simple 
touch /Applications/Firefox.app 
made the finder refresh the version number.

should be easy to make the updater do this.

Comment 12

[Doug Grinbergs]

I also saw the bug with 3.0.6 > 3.0.7 (10.5.4 iMac G5)

Required: 
- outdated app version
- Internet connection for software update

1 Finder: note app info window version
2 Open app
3 Check for updates
4 [Download and install now]
5 [Restart]
6 Finder: check app info window

Info window has previous version string
Finder info window should always show correct/current version number (and it should match About box version)

Comment 14

[LegNeato]

Requesting blocking as bug 554997 would be really bad for Firefox 4 alpha/nightly -> beta users

Comment 15

[Robert Strong (they/them - no direct email)]

Note that bug 554997 could likely be fixed specifically for this issue alone at the shell integration point in the OS.

Josh, since this is for Mac OS X do you have time to look into implementing this?

Comment 16

[Dave Townsend [:mossop]]

(In reply to comment #14)
> Requesting blocking as bug 554997 would be really bad for Firefox 4
> alpha/nightly -> beta users

Can you explain how this related to bug 554997. Would fixing this fix that?

Comment 17

[LegNeato]

Bug 554997 is caused by changing metadata underneath the OS without telling LaunchServices to get the new metadata. As such, when it goes to act on the old metadata it gets confused (can't find the app because the app bundle identifier has changed). Then, it falls back to safari as a default. When you try to set the app as default, it uses the old metadata in LS and the cycle continues.

The updater could "touch" the bundle, which causes LS to reload the metadata...but that wouldn't fix every case (users already hitting the issue won't benefit from the fix until the updater with the "touch" is laid down on disk and used).

It's probably best to either a) touch the app bundle on startup in every case or b) check the LS database on startup (and/or shutdown?), if it is out of date update it / signal LS to rescan. Not sure what that will do to perf though.

Comment 18

[Dave Townsend [:mossop]]

Sounds to me like bug 554997 is the blocker here

Comment 19

[Robert Strong (they/them - no direct email)]

Just verified that bug 600098 fixes this bug