Hi.
Today I noticed an unexpected behavior in Firefox Portable.
If I have the pref "app.update.staging.enabled" set to false, FirefoxPortable.exe is terminated while updater.exe is still running.
The pref description: "If set to true, the Update Service will apply updates in the background when it finishes downloading them."
So, the updates are applied in the background while firefox is still running (true). Otherwise, they are applied when you restart firefox (false).
When the pref is set to true, updater.exe is still called, but briefly, and triggers firefox.exe quickly afterwards.
When the pref is set to false, everything will be done by updater.exe when restarting firefox, which will take an extra time. In this case FirefoxPortable.exe is closed while updater.exe is still running.
Can you please confirm the bug?
Thanks in advance.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I don't think we ever supported or planned to support that option. Does it work correctly with the option off?
Sometimes, the impossible can become possible, if you're awesome!
Yes, with this pref set to true (default), it works correctly.
As a workaround, I've added the following line "${ProcessWaitClose} "updater.exe" -1 $R0" below "${ProcessWaitClose} "firefox.exe" -1 $R0" in the.nsi file and recompiled the .exe. It seems to work fine, but I don't know if it is a proper fix.
The problem with that approach is that it will wait for all processes called updater.exe system wide. That's why I coded it to specifically check the path to it a few lines below. I haven't checked, but if it runs it from a specific location when run in the mode you're using, I may be able to check for it.
Sometimes, the impossible can become possible, if you're awesome!
Yes, I saw those lines in the code, but apparently they only take effect if "firefox.exe" is running in the meantime when "updater.exe" is applying the updates. Is that right? If so, what approach do you suggest to wait for "updater.exe" in the same way as "firefox.exe"?
Lines 760-762 check if firefox.exe is still running and then goes back into 758 to wait for it to stop. Then lines 763 to 769 see if updater.exe is running and if it is, checks if it's the one within the current Firefox Portable. If it is, it goes back to 758 and continues again.
Sometimes, the impossible can become possible, if you're awesome!
So, when it comes back to line 758 and doesn't find "firefox.exe" running, it will terminate Firefox Portable, even if "updater.exe" is still running, right? In this case, I think the line I mentioned before is a good one. The problem is to consider "updater.exe" system-wide, as you mentioned... If there is any trick to get around this, that would be great.