User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 I have had so many problems with settings over the duration of my use of Mozilla 0.9.x -> 1.4, and seeing as many others don't, I assume they're all to do with new versions not handling old version's user settings. My current problem is that mozilla keeps crashing randomly, (as of version 1.4). So assuming the usual upgrade-not-handling-settings problems, I backed up my ~/.mozilla directory and removed it, (while mozilla was closed - absent from process list too :) I restart mozilla, and get presented with the migration dialog, ask it to migrate, then boom, it disappears. So I try starting it again, and it just disappears each time. After some playing, I find that it starts if I invoke it as: /usr/lib/mozilla/mozilla-bin <something> but not if the command line is blank. By <something> I just mean some random characters, which are then opened as a URL. So I quit all instances, remove ~/.mozilla again, and restart it.. this time not migrating, but instead creating a brand new profile. Quit... moz won't restart without a command line param. So I decide to accept this as a quirk with some library on the system, (even though it worked fine with my old profile - what was I thinking), and head for the preferences dialog to get my settings set up. *change* *change* OK, quit, restart, no saved settings. Actually that's a lie, about 10% were saved. Random ones too. For example, nothing on the root Navigator settings page will change, but Enable Internet Keywords under Smart Browsing sets and unsets fine. Note, that the settings do not remain even through an open and close of the preferences dialog. Open, change, OK, open, gone. Is it possible that settings that are stored outside my user profile, (language packs?), are the cause of this? Reproducible: Always Steps to Reproduce: 1. Change *some* settings 2. OK. Actual Results: Some settings refuse to change. Expected Results: Changed the settings and saved them, and not refuse to run when I run it without command line parameters and not randomly crash, please. This version of Mozilla is 1.4, installed via the Gentoo ebuild ('stable' version).
Just to confirm, this happens exactly the same in the binary download of 1.4 from mozilla.org.
Also to confirm, the same happens with the binary 1.5a downloaded from mozilla.org, (which btw, identifies itself as 1.4).
A very strange problem indeed :) Great that you tried it with the most recent official releases ! However, could you try this again using a recent nightly build from <http://ftp.mozilla.org/pub/mozilla/nightly/latest/> ? Thank you! Do you know if other Gentoo users have this problem ?
> /usr/lib/mozilla/mozilla-bin <something> starting mozilla-bin directly (with or without commandline arguments) shouldn't work. what do your environment variables MOZILLA_FIVE_HOME and LD_LIBRARY_PATH look like? To diagnose the crash, it would be very helpful to get a stacktrace with symbols. strace might be insightful too. > Also to confirm, the same happens with the binary 1.5a downloaded from > mozilla.org, (which btw, identifies itself as 1.4). the 1.5a build won't identify itself as 1.4. you're somehow starting the 1.4 build. try: % sh -x command_to_start_mozilla_1.5a It's conceivable that your attempt to use .mozilla.org's 1.4 binary also didn't work (your system grabbed the gentoo version).
You are utterly correct, I failed to notice that Gentoo sets MOZILLA_FIVE_HOME on login. Unsetting that and re-running the release binaries, allows them to work fine. So the issue is with the Gentoo build.. unfortunately I would like to use the Gentoo build, as the fonts are much less pitiful. I have tried linking against GTK+ and GTK+2, same issue in both cases, (is GTK2 considered stable for use with Mozilla now?). Otherwise, it's going to be a gentoo bug report, isn't it? Could anyone tell me what configure options are considered safe when building Mozilla?
resolving INVALID based on comment 5
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.