295585 - middlemouse.contentLoadURL resetted after using lx profil on windows

Status: RESOLVED EXPIRED

(Firefox :: Shell Integration, defect)

Description

[phoBOS]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2)

I set middlemouse.contentLoadURL to false on windows, to let it act like in windows.
But I use this profile for windows and linux.
After using my profile under windows middlemouse.contentLoadURL is resetted to
the default value and I have to set it to false again, when I use the profile
under linux.

Reproducible: Always

Steps to Reproduce:
1. create a profile which can be accessed from windows and linux.
2. Start FF under linux
3. set middlemouse.contentLoadURL to false
4. stop FF
5. Start FF under windows, using the same profile.
6. stop FF
7. Start FF un linux again
8. Middle-Klick on a tab or see about:config.

Actual Results:  
You will see that middlemouse.contentLoadURL has been resetted.

Expected Results:  
The middlemouse.contentLoadURL option should also been keept in the windows
version of FF.
Also I FF on windows does not need this funktion.

This problem can also accour with other variables...


The Mozilla Suite could have the same problem.

Comment 1

[Ava3ar]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050525 Firefox/1.0+

it doesnt get reset in trunk, but thanks for that info i was looking for how to
make that work

Comment 2

[Mike Connor [:mconnor]]

Sharing profiles between Windows and Linux isn't actually supported at present,
but its interesting that it seems to work well now.

As for the issue here, changing a preference, then running a build where that
setting is the default, causing the preferences backend to drop that pref from
the set of changed prefs.  There 

Best workaround is to set the prefs you want to lock into place in user.js.

This is a dupe of untold other bugs.

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.