|
Bugzilla – Full Text Bug Listing |
| Summary: | Firefox loses parts of the configuration on update | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Reinhard Max <max> |
| Component: | Firefox | Assignee: | E-mail List <bnc-team-mozilla> |
| Status: | RESOLVED NORESPONSE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | asklein, axel.braun, suse-beta, vetter |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Reinhard Max
2006-03-13 15:28:39 UTC
That's another strange thing. I update my Firefox often as you can imagine and never saw such a behaviour. The first thing you mention should only happen by setting middlemouse.contentLoadURL to false but the software default if nothing is set is true. Do you still have a "broken" profile where you can check your prefs.js? No broken profile left, but when I look for middlemouse.contentLoadURL in about:config, it indicates that the default is "false", and it seems to be falling back to that default on some (not all) updates, even when the version number of FireFox hasn't changed. that's strange. My default is "true". Could you please grep in /usr/lib/firefox for contentLoadURL? Did so, and some further inspection of the result brought up this:
$ grep -i middle /usr/lib/firefox/greprefs/all.js
// Middle-mouse handling
pref("middlemouse.paste", false);
pref("middlemouse.openNewWindow", true);
pref("middlemouse.contentLoadURL", false);
pref("middlemouse.scrollbarPosition", false);
// Middle-mouse handling
pref("middlemouse.paste", true);
pref("middlemouse.contentLoadURL", true);
pref("middlemouse.openNewWindow", true);
pref("middlemouse.scrollbarPosition", true);
That's the same for me. The reason is that the file gets "compiled" with platform ifdefs and includes a default first and the Linux ifdef afterwards. Maybe somehow/sometimes this double setting confuses the pref system. (although I never saw this, this might happen under special circumstances) I'll see what can be done. Could it be that something like a syntax error makes Firefox silently stop parsing the file after it has seen the generic version of middlemouse.contentLoadURL, but before it gets to see the Linux-speciffic one? A syntax error could cause this I think. But I guess you didn't modify your global prefs? Can you attach your all.js to this bug? If the default in all.js was changing, that would explain this bug. When it changes to 'true' we'd wipe out your preference in prefs.js because it is the default. Then when it changes to 'false' you'd lose your preference. (In reply to comment #8) > If the default in all.js was changing, that would explain this bug. When it > changes to 'true' we'd wipe out your preference in prefs.js because it is the > default. Then when it changes to 'false' you'd lose your preference. That's what I've thought before in the other bug mentioning this. But the contentLoadURL pref was true for Linux at least since 1.0.x up to our 1.5.0.1 package AFAIK. FWIW, it happened again when updating from (IIRC) beta6 to RC1. ...and on 10.0, when updating to FF 1.5.0.2 It didn't happen when I updated from 10.1 RC1 to RC2. ... and it happened again when I updated from RC2 to RC3 :( ... and again when I tested SLES10 (Firefox 1.5.0.4) and then again when switching back to 10.1 (Firefox 1.5.0.3). woa....1.5.0.4, 1.5.0.5, 1.5.0.6....every update the same story.....is this bug persistent? Any updates on how the upgrade to 2.0.0.* went? Is this still an issue? assuming so |