Firefox Portable doesn't backup/restore the Crash Reporter keys. This is the preference under Advanced -> General -> "Submit Crash Reports".
Steps to Reproduce:
- Start Firefox Portable
- Go to Options
- Hit the Advanced tab, then General
- Disable
Submit Crash Reports - Close Firefox Portable
- Observe that a registry value has been created without cleanup.
HKCU\Software\Mozilla\Firefox\Crash Reporter\SubmitCrashReports
If local Firefox is installed, the crash reporter key will already be created. Delete the values beforehand to test.
I talked to JohnTHaller on IRC about this a while back. I believe this is a known bug, just leaving this here for reference.
This bug is introduced in Firefox 16. Ironically, I made the patch to create this registry key in bug 577221.
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
Ah yes. I think we were debating whether to disable the ability to submit crash reports from the portable version at the time. I think we'll leave it enabled and backup/restore this key (so as not to impact the local version if there is one). We'll ignore it when multiple instance mode is on (as it's not fully portable or supported anyway). I have a fix prepped and will include it in the next release after 17.0.1 (which is already built and mirrored). Until then, just don't use crash report submission.
Sometimes, the impossible can become possible, if you're awesome!
As planned, this has been fixed in Firefox Portable 18.0.
Sometimes, the impossible can become possible, if you're awesome!
Nope, the issue is still there.
As always, if you use AllowMultipleInstances, it will be left behind. It works in proper Firefox mode.
Sometimes, the impossible can become possible, if you're awesome!
Nope, I tried with AllowMultipleInstances=false, and the issue is still there.
With the default settings, it works fine here on Windows 7. By default, I mean no FirefoxPortable.ini file.
Sometimes, the impossible can become possible, if you're awesome!
I've tried without that file and the issue is still here.
FirefoxPortable was downloaded from that page: https://portableapps.com/apps/internet/firefox_portable
it says it's last update was 8th of Jan, 2013
I'm on W7SP1x64.
The issue here is different from one you reported in the other thread. The one here is fixed. Please don't cross post. Thanks.
my posts in this thread are not related to the other topic. The issue described in this topic is still reproducible for me.
The issue in this bug is only about the registry key being left behind. Are you positive the registry key is left behind on your PC with a default install of Firefox Portable? This bug doesn't have anything to do with the actual Crash Reports left behind in a folder, it's only about the registry key that controls the setting to enable/disable it.
Sometimes, the impossible can become possible, if you're awesome!
Yes I am positive.
I've doublechecked.
I downloaded a new clean instance of FirefoxPortable from this site (english version), installed it (unpacking + downloading, as far as I understand) and tested the bug described in this thread.
Then I go to registry and delete HKCU\Software\Mozilla completely.
Then I uncheck the mentioned checkbox and go to HKCU\Software in regedit again: I hit f5 to reload the tree and notice that "mozilla" gets re-created, it contains "firefox", which contains "Crash Reporter", which contains a key "SubmitCrashReport" REG_DWORD 0x00000000 (0).
For me this means that the bug is still here.
+ for the record:
I've also just noticed that if I uncheck that checkbox and then hit f5 in regedit and delete the whole "HKCU\Software\Mozilla" key, and then close and re-open firefox' settings, and then again hit f5 in regedit - I get "HKCU\Software\Mozilla" key restored.
That key contains "Firefox" key, which contains "Crash Reporter" key and none of them have any values.
Does the key remain after you close Firefox. Multiple keys are always created while Firefox is running, but the launcher cleans them up as Firefox closes.
Sometimes, the impossible can become possible, if you're awesome!
Yes, it does. In both cases: when that checkbox is checked and when it is unchecked.
is it possible that you just forgot to include the patch/fix into the builds on this page?
I can confirm the issue is still present. Is triggered when HKLM\Software\mozilla.org doesn't exist on the local machine due to an error in the logic of the cleanup routine. When that key doesn't exist, it doesn't properly cleanup the HKCU keys. Basically, the key isn't properly cleaned up on machines with no Mozilla apps installed locally. This launcher should do the trick:
https://portableapps.com/downloads/app_extras/firefox_portable/crash-reg...
Sometimes, the impossible can become possible, if you're awesome!
Tested. The issue is fixed. Thanks.
The checkbox state seems to get remembered regardless of presence of that key.
Is it possible to block the action, when Firefox tries to create that key?
creating/deleting registry keys may be logged, so FirefoxPortable loses a bit of stealth.
Not without recompiling Firefox from source.
This is now fixed for PCs without an existing mozilla.org key as well as those with one in 18.0.1.
Sometimes, the impossible can become possible, if you're awesome!