(In reply to Duncan McIntosh [:dmcintosh] from comment #10) > Thank you! The 'updated by another instance' part is very interesting. I'm guessing you don't have any other Firefox windows open? It may very well be that they do not. This problem is caused by Firefox trying to launch a new process and discovering that the new process is the wrong version. We don't actually _know_ that it was another instance of Firefox. And, in this case, it sounds like the update was installed manually. --- (In reply to bugzzzz from comment #8) > My personnal installer just extract the tarball in /usr/local, remove the old symbolic link and create a new link to the last version. This makes it sound very possible that the old instance can't find its binary to launch new processes because the path it's using includes that link. If so, we could potentially address that by getting resolving the links on startup and caching the path. But I suspect that the actual fix for this is gonna be Bug 1609882/Bug 1705217 rather than going to the trouble to handle this one case differently.
Bug 1963073 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Edit: Never mind I got this wrong. I misread the bug. Sorry! (In reply to Duncan McIntosh [:dmcintosh] from comment #10) > Thank you! The 'updated by another instance' part is very interesting. I'm guessing you don't have any other Firefox windows open? It may very well be that they do not. This problem is caused by Firefox trying to launch a new process and discovering that the new process is the wrong version. We don't actually _know_ that it was another instance of Firefox. And, in this case, it sounds like the update was installed manually. --- (In reply to bugzzzz from comment #8) > My personnal installer just extract the tarball in /usr/local, remove the old symbolic link and create a new link to the last version. This makes it sound very possible that the old instance can't find its binary to launch new processes because the path it's using includes that link. If so, we could potentially address that by getting resolving the links on startup and caching the path. But I suspect that the actual fix for this is gonna be Bug 1609882/Bug 1705217 rather than going to the trouble to handle this one case differently.