775937 - Settings>Startup>Homepage: User settings will be overwritten by mozilla.cfg (not using "lock_pref")

Status: RESOLVED WORKSFORME

(Core :: Preferences: Backend, defect)

Description

[Stefan Lippke]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

with Software Deploying a set of local-settings.js, mozilla.cfg and overide.ini ist deployed. We used this also in Version 11. 
Example within our mozilla.cfg (anonymized):
// set Homepage
pref("browser.startup.homepage","http://intranet");

Now it takes the effect, that user settings of the homepage are overwritten in every case. In version 11, we used before, and 15b1 it works correct


Actual results:

Now it takes the effect that user settings of the homepage are overwritten in every case. In version 11, we used before, and 15b1 it works correct


Expected results:

Usersettings (hold in <Mozilla-userprofile>prefs.js) should have higher privileges than the settings in mozilla.cfg, when they are not locked with "lock_pref"

Comment 1

[Matthias Versen [:Matti]]

It's only an issue in Firefox 14.0.1 ?
Could you please check a nightly build to be sure that this is really fixed ?
- ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/

The next fix for Firefox 14.0.1 will be Firefox15 except if there is an emergency security release.

Comment 2

[Stefan Lippke]

Thank you for your answer. 

In the meantime I´ve searched for further information. Until now, I didn´t know the function call "defaultPref" - now I do!

But unfortunatly it does not work either. I´ve done this:
- change in the mozilla.cfg "pref" to "defaultPref"
  // set hompage
  defaultPref("browser.startup.homepage","http://www.mozilla.de");
  // ask for Download Folder
  defaultPref("browser.download.useDownloadDir", false);
- as the second parameter works fine, the homepage is set (you can see in the about:config) but is not shown after running firefox.
- is there any other parameter to be set (something with "override")?

The intention to this issue has changed a little bit caused by my not-knowing all parameters, sorry for that.

Comment 3

[Stefan Lippke]

I made some tests on the versions 15.0b1 and the nightly build 16.0a2. Both seem to process only a few parameters of mozilla.cfg. The most settings there will be ignored. 

This are the results of the tests:
//our Firefox Default Settings tested with Firefox 15.0b1 and 16.0a2

// set hompage
// IGNORED 
pref("browser.startup.homepage","http://www.mozilla.de");

// ask for Download Folder
// IGNORED 
pref("browser.download.useDownloadDir", false);

// set autom. Updates
// IGNORED 
lockPref("app.update.enabled", false);
// IGNORED 
lockPref("app.update.auto", false);
// IGNORED 
lockPref("app.update.mode", 0);

// set Direct2d Disabled (Hardware-Acceleration)
// IGNORED 
pref("gfx.direct2d.disabled", true);
// IGNORED 
pref("layers.acceleration.disabled", true);

// Hide 'know your rights' button at first run
// DONE
pref("browser.rights.3.shown", true);

// swtich off sending anonymized performancedata to Mozilla
// DONE
pref("toolkit.telemetry.prompted", 2);
// IGNORED 
pref("toolkit.telemetry.rejected", true);

//set proxy server settings
// IGNORED 
lockPref("network.proxy.autoconfig_url", "<path to proxy>");
// IGNORED 
lockPref("network.proxy.type", 2)

Obviously someone else figured out this: http://forums.mozillazine.org/viewtopic.php?f=23&t=2504597&p=12147857

Comment 4

[Matthias Versen [:Matti]]

I'm very busy this week and I can't test this myself.
The best way to get this fixed is to find a regression range if this worked in a previous version.

You would have to download some (~8) builds and test them until you find the first bad and the last good one. We have a automatic tool for that but in this case you have to do that manually to place to lock files.

Would you do the work ?
I will provide a description of the process.

Comment 5

[Stefan Lippke]

Yes, I will do that. Because I´m also busy it may take a while. First I have to deploy the firefox 14 with defaultpref for our homepage and without touching existing homepage-settings...

If you have some hints or links, let me know

Comment 6

[Mike Kaply [:mkaply]]

There was a separate bug files for locking prefs not working (bug 776490)

I tracked down the regression to between:

2012-04-29-03-05-04-mozilla-central
and
2012-04-30-03-05-04-mozilla-central

http://hg.mozilla.org/mozilla-central/rev/8f377102841b
and
http://hg.mozilla.org/mozilla-central/rev/cfaf90b22fc3

Comment 7

[Matthias Versen [:Matti]]

To clarify this: There was a regression in Firefox13 and that is bug 776490 and there is an additional regression in Firefox15 that only some lines of a mozilla.cfg are processed ?

Comment 8

[Mike Kaply [:mkaply]]

bug 776490 is the Firefox 15 regression that mozilla.cfg mostly doesn't work at all.

I've verified that everything works fine in FF14.

In reading this bug, I'm unclear as to what the actual bug being reported is, and whether it is a Firefox 13 problem or some other versions.

There were changes made to the precedence of preferences, but I'm not sure what release that was in.

Comment 9

[Stefan Lippke]

Primarily I noticed a changed behavior from Version 11 to 14 (This was the step we made with Firefox deploying): The pref in mozilla.cfg "browser.startup.homepage" set our intranet to a new Mozilla profile and didn´t touch settings done by the customer. In version 14 we noticed, that the effect has changed: The homepage is always set to this parameter at startup. First I thougth, it was a bug (because of that I opened this bugreport). I found  - while searching other solutions - a third types of prefs, defaultPref, and tried to change my configuration with defaultPref, without success.
My question is: Does it work as designed, when the line in mozilla.cfg
defaultPref("browser.startup.homepage","http://www.mozilla.de");
set the parameter (you can see it in about:config) but you never can see the homepage at startup and additional you may not set this page in the Options GUI or is this actual a bug?

If it works as designed please give me a hint how to set an init parameter for the homepage only for the first run without an existing Mozilla profile. For my opinion we can then close this bugreport.

Thank you

Comment 10

[Mike Kaply [:mkaply]]

You can read more information here:

http://mike.kaply.com/2012/03/16/customizing-firefox-autoconfig-files/

But here's how it works now in Firefox 14 (and it does work correctly). It was broke in previous builds (after Firefox 10, but before Firefox 14)

defaultPref("browser.startup.homepage", "http://www.yahoo.com");

This sets the default value of the preference. What that means is that if the user never changes it, it will be set to this value.

pref("browser.startup.homepage", "http://www.yahoo.com");

This changes the value of the preference as if the user had set it. That is, it overwrites the user's value.

lockPref("browser.startup.homepage", "http://www.yahoo.com");

This sets the default value of the preference and locks it so the user can't change it.

So if your goal is to change the homepage, but don't change it for users that have already set it, you should use defaultPref.

If your goal is to force the user to use a certain homepage, use lockPref.

If your goal is to do change the homepage back every time the browser starts, use pref.

Comment 11

[Stefan Lippke]

Hello Micheal,

thank you for your explanation in detail. Sorry for my delayed answer, I´ve been out of work for sometime. I have tested your settings: While "pref" and "lockPref" work properly, with "defaultPref" I see these effects:
Predefinitions
- In the options firefox is set to "Show my home page"
- Home Page is set on "Mozilla Firefox Start Page"
- clicking on the homepage button shows the "Mozilla Firefox Start Page" (about:home)
- The config mozilla.cfg file has the line 
  defaultPref("browser.startup.homepage", "http://www.yahoo.com");
- in "about:config" "browser.startup.homepage" is set to "http://www.yahoo.com" (Status default)

If I set "browser.startup.homepage" to another homepage like "www.mozilla.org" (in "about:config") this option changes to "browser.startup.homepage" with value "http://www.mozilla.org" (Status user set). This change is also viewable in the options and it works.

After a reset the old settings done by mozilla.cfg comes back ("browser.startup.homepage", Value "http://www.yahoo.com", Status default) and does not work

Changing the homepage settings in the options sets this parameter to the new setting and all works fine.

So only the setting by mozilla.cfg has no success (only in my environment...?)

I´ve tested the german and en-US version of Mozilla Firefox 15b05.


I hope you can help me.

Greetings

Comment 12

[Mike Kaply [:mkaply]]

Can you try this and see if it works?

defaultPref("browser.startup.homepage", "data:text/plain,browser.startup.homepage=http://www.yahoo.com");

I know it looks strange. Trust me :)

Comment 13

[Stefan Lippke]

It runs!!
Now this parameter works nearly as expected. Nearly means, that the addition data:text/plain only may be written in the config file mozilla.cfg

If you write the same directly in (about:config) browser.startup.homepage you´ll get this line shown instead of the internetpage. But it makes no difference if one knows about this behavior.

For me all is ok, for my intention it works as expected.

One question: Is this a bug, that will be solved in the future or is this the way to set this parameter with mozilla.cfg?

Thank you for your help!

By the way: I´ve trusted you in any moment...

Comment 14

[Mike Kaply [:mkaply]]

> Is this a bug.

That's a great question :)

Yes and no.

The behavior itself is not a bug. The default homepage is a complex preference, so it has to be specified that way. It's annoying, but that's the way it's been forever.

It creates even more problems when you lock it. If you decide to lock it, you can't use the complex preference. That's a bug

https://bugzilla.mozilla.org/show_bug.cgi?id=333049

Comment 15

[Stefan Lippke]

So then for me all is clear and I set this bugreport to RESOLVED. 

Thanks a lot for all your help. This kind of communtiy causes the trust in Mozilla and its products.