234846 - Some contents of user.js are not reflected in pref.js.

Status: RESOLVED WORKSFORME

(Camino Graveyard :: Preferences, defect)

Description

[Hiro]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7a) Gecko/20040218 Firefox/0.8.0+

A part is not reflected in pref.js although the option which cannot be set up
from Preference of Camino is set up by user.js.

What I have noticed is as follows.
  user_pref("network.http.pipelining", true);
  user_pref("network.http.pipelining.maxrequests", 8);
  user_pref("network.http.sendRefererHeader", 1);

And about the following parameter, it became effective by registering with
direct pref.js.
    user_pref("network.http.sendRefererHeader", 1);

But, about the other parameter, although pref.js was checked after the end of
Camino, it had disappeared.
Although the same thing was checked by Mozilla Firebird, it was registered
normally to pref.js.

Are there any restrictions in Camino?
Of course,Camino is stopped when correcting a setting file.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Hiro]

Attachment: My user.js

FYI.
This is My user.js file.

Comment 2

[Hiro]

This is not reflected in pref.js, either, although customize of "Cookies" was
tried as follows.

  Contents added to user.js:
  user_pref("network.cookie.cookieBehavior", 1);

  Reference page:
  http://www.mozilla.org/quality/networking/docs/netprefs.html

About the problem of this "Cookies", I think that it is because hard coding is
carried out by the following processings.
http://lxr.mozilla.org/mozilla/source/camino/src/preferences/PreferenceManager.mm#295

Comment 3

[Stuart Morgan]

Re comment 2, that's fixed by the patch for bug 182540.

Comment 4

[Hiro]

(In reply to comment #3)
> Re comment 2, that's fixed by the patch for bug 182540.

No.
This problem is not a problem of only Cookie.

Comment 5

[Stuart Morgan]

Trust me, it is; the patch for bug 182540 fixed the issue of cookie behavior
changing from 1 to 2.

As for the rest of the bug, I'm not sure I understand the problem. Is it simply
that when you put things in prefs.js, they are deleted later? That's expected
behavior, which is why user.js exists.

Comment 6

[Hiro]

>That's expected
>behavior, which is why user.js exists.

Yes.
And there is still a thing with which the contents written down in user.js are
not reflected in pref.js.
As what I can be checking, it is the parameter reported first.

Comment 7

[Mike Pinkerton (not reading bugmail)]

i dont' understand what the problem here is.

Comment 8

[Hiro]

A Gecko product can customize various options which cannot be set up by
Preference by user.js.

But it means that only Camino cannot be set up like comment#0.

Comment 9

[Stuart Morgan]

Ok, now I get it. What I didn't undertand was that any non-default user.js prefs
should be written to pref.js (which I find really stupid, but whatever).  The
network.http prefs listed in the bug don't get propagated, despite being
non-default, which suggests that Camino is preventing them from being set at all.

Comment 10

[Akkana Peck]

I just had a similar problem: some prefs in user.js were picked up, others weren't.

It turned out that I was missing a semicolon on one line halfway through
user.js, and anything after that point was silently ignored.

I filed bug 278878 on the core rather than trying to hijack this Camino bug.

crot0: If you haven't already, try moving the relevant lines to the very top of
user.js, or moving your user.js aside and making a new one containing only those
lines.  If that works, then you can narrow down where the error happens by
putting the lines you're testing halfway through the file, then 1/4 or 3/4 of
the way through the file, etc. until you find the line that's causing the
problem.  If you find it was a syntax error, join that other bug and mark it as
platform=all.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

crot0, can you update?  Do the pipelining prefs still not get reflected into
prefs.js?

Comment 12

[Hiro]

(In reply to comment #11)
> crot0, can you update?  Do the pipelining prefs still not get reflected into
> prefs.js?

Yes, when only the pipeline option was set to user.js, the option was reflected. 
And it was N.G when trying with My user.js that did attach. 

When having examined it, the setting was reflected when the same setting
"user_pref("network.http.version", 1.1);" as 
the default value was removed. 

The default value of this option is "1.1" now.
http://lxr.mozilla.org/mozilla/source/modules/libpref/src/init/all.js#483 
The default value might have changed before it knew because it had used this "My
user.js" for a long time. 

And, Camino might stop reading the setting then when the same setting as the
default value is in user.js.

It will reflect all the settings disregarding the setting of the default value
because it is impossible to understand when the default value is changed if this
guess is correct. 

Comment 13

[Simon Fraser [no longer active]]

Just tried it; works fine.