Hi,
I am able to use the WaitForFirefox=true properly but on initial start after copying on a machine, it doesn't wait for the first time.
Anything I can do here?
New: System Informer (Apr 21, 2024), Platform 29.5 (Apr 24, 2024)
1,000+ portable packages, 1.1 billion downloads
Please donate today
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
Sorry vigyaan, I can't help you...
But, no matter how many times I've tried, I have ALWAYS reproduced this problem! With any instance of Firefox Portable, dating back to 3.0.xx series! It is definitely a bug which seems to have been missed by the developers. I first noticed it a little while ago with Adobe Flash Player Portable, and I have been in contact with Pyromaniac (developer of AFPP) about it. However, he wasn't able to confirm it... He tried to fix it, but couldn't have done so with a simple solution. It seems it's just something hard-coded in FFP launcher. I hope one of the developers takes a look into the problem and tries to fix it.
The problem appears on first run ONLY, when FFP is freshly installed OR if you delete the Data folder and then run it. So it seems that FFP launcher is dependent in some way on saved settings in Data folder, and fails to WaitForFirefox if the launcher needs to create the settings.
PS: vigyaan, can you add "[BUG]" (without the quotes) into the name of the topic. I don't want to create a separate topic just for that, and due to the "Question" part in the current name, your topic is (most likely) being skipped by the developers, since there's always "someone from the community" available to answer any questions...
@developers: if you want to recreate the problem, then it's very easy with any version of FirefoxPortable you released. Just make sure you delete the Data folder, and make sure that FFP launcher needs to do something when firefox.exe finishes (something for the launcher to execute). Whoa-la! The thing FFP launcher was supposed to execute after firefox.exe has finished was executed at the same time as firefox.exe!
I hope that you haven't missed the same bug and released it in all the other apps, but I don't care about them so much and haven't checked for it yet (after all, FirefoxPortable is the one most often to be executed on foreign computers, and most likely to need an update if available).
My posts are old and likely no longer relevant.
thanks dboki89 for the message and the reproduction of the issue. I hope this gets fixed soon, but for now I have to take defensive measures on first boot.
I can always reproduce this issue and found out that the Portable launcher waits until real firefox process is terminated. Sadly, on the first run firefox probably scans all plugins, writes in a cache file and restarts itself and get a new process id. Thats why the portable launcher sees that the original firefox process is terminated and closes itself.
How can someone prevent the restart of firefox after first run?
Support for this setting was dropped. It is no longer included in the example INI but is mistakenly included in the readme. It will be removed on the next release.
On first launch, FFP correctly waits around for Firefox to exit on all tests I have done. It waits only when it needs to, depending on the state of the local machine (sometimes with a local FF install, it does not need to wait). It will always wait on RunLocally. It will not wait when you use AllowMultipleInstances, which should only be used on your own machine.
AFPP's launcher is unofficial and completely unsupported (and actually a trademark violation, so I will have to pull it).
Sometimes, the impossible can become possible, if you're awesome!
If you are referring to the icon, it is changed. The icon has been changed to the one that is free for non-commercial use. Just ask Pyromaniac for the link of the icon and you'll see that it is free to use (it is NOT the default trademarked FF logo). And there is no FF software in it, since it's just the launcher. There is no Adobe software in the installer, since it's an online installer. So where is that trademark violation?
Added: The link for the icon in use by Adobe Flash Player Portable can be found here - http://www.iconspedia.com/icon/firefox.html
For more details, contact Pyro...
Finally! Found my culprit! I haven't thought of the fact that that setting might be interfering with WaitForFirefox...
Now it makes sense. I always edit FirefoxPortable.ini to disable splash, allow multiple instances (I have a good reason) and similar. And that explains why Pyromaniac couldn't have reproduced the problem, but for me it appeared in all versions of FFP...
Thanks for the clarification
Why removed from the app? Oh well, I guess you can't win them all
As I understand it, you are dropping more currently supported options from your apps because of the PALauncher? Or just trying to "make it simple"?
Take care
EDIT: Added quotes, a link, and extended my original reply.
My posts are old and likely no longer relevant.