Last Comment Bug 779437 - Setting autoDisableScopes via default preferences is broke in Firefox 14
: Setting autoDisableScopes via default preferences is broke in Firefox 14
Status: RESOLVED INVALID
: dev-doc-needed
Product: Firefox
Classification: Client Software
Component: Preferences (show other bugs)
: 14 Branch
: x86 Windows 7
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-01 01:34 PDT by Dimas
Modified: 2012-11-02 11:42 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
-
-


Attachments

Description Dimas 2012-08-01 01:34:16 PDT
Updating to Firefox 14 disables all the addons in %ProgramFiles%\Mozilla Firefox\extensions ignoring autoDisableScopes pref set via default preferences (defaults/pref).

To reproduce:
- Install Firefox < 14
- Create a file in defaults/pref with: pref("extensions.autoDisableScopes", 0);
- Install some addons to %ProgramFiles%\Mozilla Firefox\extensions
- Install Firefox 14
- All the extensions in %ProgramFiles%\Mozilla Firefox\extensions are disabled.

Mike Kaply made some regression testing and seems to be broken between:

2012-05-31-03-05-17-mozilla-central
http://hg.mozilla.org/mozilla-central/rev/3aa566994890
AND
2012-06-01-03-05-20-mozilla-central
http://hg.mozilla.org/mozilla-central/rev/73783bf75c4c

on mozilla-central.
Comment 1 Mike Kaply [:mkaply] 2012-08-01 06:36:50 PDT
Here's the pushlog.

hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3aa566994890&tochange=73783bf75c4c

I did a great deal of investigation into this and what I discovered is that putting the file in defaults/preferences seems to work, whereas putting it in defaults/prefs works.

What's especially odd is that setting of new preferences in defaults/pref works but overriding default prefs doesn't seem to work (although occasionally it works).

I believe this is related to the webapps work that Myk Melez did in bug 746156

I can't find any good explanation of what the relationship between default/prefs and default/preferences

Copying people in the know.

BTW, someone will probably say "Just put the file in defaults/preferences" and this is simply wrong. We've been telling people to use defaults/prefs for many years. This is a deployment issue.
Comment 2 Mike Kaply [:mkaply] 2012-08-01 09:56:24 PDT
This is an even bigger issue than I thought.

Linux vendors put their JS files in defaults/pref as well.
Comment 3 Robert Strong [:rstrong] (use needinfo to contact me) 2012-08-01 13:19:20 PDT
I also suspect bug 746156 as the cause though I don't know a good explanation as to why. Perhaps Myk or Benjamin (reviewer - bug 746156 comment #2 though he is away atm) know what's going on. Also adding Blair since this involves the add-ons manager.
Comment 4 Myk Melez [:myk] [@mykmelez] 2012-08-01 13:24:42 PDT
In the Firefox installation directory there are two default preferences directories, defaults/pref/ and defaults/preferences/.  defaults/pref/ is for GRE defaults that apply to all applications using the GRE that comes bundled with Firefox, while defaults/preferences/ is for app-specific defaults that apply only to Firefox.

Until recently, Firefox's default prefs files were in the defaults/pref/ dir, even though they should have been in defaults/preferences/. Bug 725408 (and/or a followup fix) moved them to the correct location so they don't get applied to the webapp runtime, which is a GRE-based app that we now ship with Firefox.

In Firefox, prefs files are read first from defaults/pref/ and then from defaults/preferences/ (in reverse alphanumerical order within each dir).  So prefs you specify in a file in defaults/pref/ will apply to Firefox, but they may be overridden by prefs specified in a file in defaults/preferences/.

Thus, to ensure your preferences are not overridden, specify them in a file in defaults/preferences/ that comes before the Firefox default prefs files alphanumerically (like autoconfig.js, which comes before firefox-branding.js and the rest of them).

Note: although we made the change for the webapp runtime, we'll also need it to ship a Metro-compatible executable for Windows 8 alongside the classic one, so bsmedberg is further separating app resources from GRE resources in the installation directory.  Thus you cannot count on those resources being intermingled in the future, and you should not do so.


(In reply to Michael Kaply (mkaply) from comment #1)
> BTW, someone will probably say "Just put the file in defaults/preferences"
> and this is simply wrong. We've been telling people to use defaults/prefs
> for many years. This is a deployment issue.

I don't know who "we" is in this case, but it is incorrect to put Firefox-specific preferences in defaults/pref/, even if it happened to work in the past.


(In reply to Michael Kaply (mkaply) from comment #2)
> This is an even bigger issue than I thought.
> 
> Linux vendors put their JS files in defaults/pref as well.

If they intend for those files to apply to all GRE applications (as they may: some Linux vendors ship the GRE as a separate, dependent bundle from GRE-based applications like Firefox and Thunderbird), then they are putting those files into the correct location.

cc:ing Takanori MATSUURA and Mike Hommey, both of whom have experience with Linux distribution strategies (as evidenced by bug 747041 and bug 762864) in case they have any insight into Linux vendor use of the two default prefs dirs and whether any Linux vendors will need to update their packages to use them correctly.
Comment 5 Mike Kaply [:mkaply] 2012-08-01 14:05:56 PDT
My experience this far is with ArchLinux which is putting their Firefox specific customizations in defaults/prefs/vendor.js

My problem with this change is that you're talking about a directory that didn't exist in a Firefox install until Firefox 14.

So to say "the files should have always been in defaults/preferences" when there was only a defaults/prefs directory is kind of silly.

Did the prefs/preferences directory distinction exist before Firefox 14? Or was it invented for Firefox 14?

How would someone have known to put things in defaults/preferences when there is not a single piece of documentation that even mentions such a directory?
Comment 7 Dimas 2012-08-01 15:17:58 PDT
Myk, with responses like yours I don't think I'll be able to continue defending Firefox distribution in our (any) company. We used the /defaults/pref until now because the available documentation says that. And now this method is disabled without warning (you have channels to do that) causing BIG problems to many users and your response is that is our fault?

Is that a Mozilla official response to the problem? I hope not, but if it means that such problems will recur in the future and we can afford it.

(Sorry for my English)
Comment 8 Myk Melez [:myk] [@mykmelez] 2012-08-01 16:26:59 PDT
(In reply to Michael Kaply (mkaply) from comment #5)
> Did the prefs/preferences directory distinction exist before Firefox 14? Or
> was it invented for Firefox 14?

Yes, it existed well before Firefox 14.  I'm not sure exactly when it was introduced; perhaps when we started building Firefox as a XULRunner (i.e. GRE) application, which was at least as of Firefox 3, if not earlier.

And I don't know why the documents you reference mention defaults/pref/.  Perhaps they were written before defaults/preferences/ was introduced, and they haven't been updated since.  Or perhaps their authors didn't know about the distinction between the two directories.


(In reply to Dimas from comment #7)
> We used the
> /defaults/pref until now because the available documentation says that. And
> now this method is disabled without warning (you have channels to do that)
> causing BIG problems to many users and your response is that is our fault?

Dimas: I didn't assign fault, and I'm not blaming you.  You seem to be reading some malice into my comment that I definitely did not intend.  I'm sorry you were surprised by this change.  Had I known it was going to surprise you, I would have communicated it via additional channels.


> Is that a Mozilla official response to the problem? I hope not, but if it
> means that such problems will recur in the future and we can afford it.

No.  My comment, like Bugzilla comments generally, is my personal response to the issue reported in this bug report.
Comment 9 hartnegg 2012-08-03 02:14:09 PDT
FYI, I just tested in Firefox 10-ESR a file defaults\preferences\autoconfig.js with these contents:
   pref("general.config.obscure_value", 0);
   pref("general.config.filename", "mozilla.cfg");
and can confirm that it does have the desired effect, also in this version.
Thus people using ESR versions need not (should not?) wait for version 17, but make this change with the next version.
Comment 10 crxssi 2012-10-31 10:41:39 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #8)
> And I don't know why the documents you reference mention defaults/pref/. 
> Perhaps they were written before defaults/preferences/ was introduced, and
> they haven't been updated since.  Or perhaps their authors didn't know about
> the distinction between the two directories.

Most of us STILL don't completely understand the difference.  I will say I have been SEVERELY affected by all this nonsense and will confirm that none of the documentation on mozillazine says anything about "defaults/preferences", everything says "defaults/pref."  And Linux Firefox from ftp.mozilla.org is still being distributed without a "preferences" directory.

Worse- some settings work only in pref/firefox.js others only in preferences/firefox.js and others only in prefs.js (or some complex mix between those and others).  And the differences in which settings must go where are not documented that I can find.  It is such a mess I plan on giving up and just using symlinked user.js files for all users back to a central place and use THAT instead (which has other effects) because it is the only place where it seems all settings are honored.
Comment 11 Myk Melez [:myk] [@mykmelez] 2012-11-02 11:42:24 PDT
(In reply to crxssi from comment #10)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #8)
> > And I don't know why the documents you reference mention defaults/pref/. 
> > Perhaps they were written before defaults/preferences/ was introduced, and
> > they haven't been updated since.  Or perhaps their authors didn't know about
> > the distinction between the two directories.
> 
> Most of us STILL don't completely understand the difference.

Which aspects of the difference do you still not understand?


> Worse- some settings work only in pref/firefox.js others only in
> preferences/firefox.js and others only in prefs.js (or some complex mix
> between those and others).  And the differences in which settings must go
> where are not documented that I can find.

As noted in comment 4:

* defaults/pref/ hosts platform preferences (where "platform" in this case is the Mozilla platform on which applications like Firefox are built);
* defaults/preferences/ hosts application (i.e. Firefox) preferences;
* defaults/pref/ is processed first, after which defaults/preferences/ is processed;
* files in each directory are processed in reverse alphanumerical order;
* prefs set later override identical prefs set earlier.

Thus, given the following directory structure:

defaults/
  pref/
    bar.js
    channel-prefs.js
    foo.js
  preferences/
    baz.js
    firefox.js
    
Files are processed in the following order:

* defaults/pref/foo.js
* defaults/pref/channel-prefs.js
* defaults/pref/bar.js
* defaults/preferences/firefox.js
* defaults/preferences/baz.js

So baz.js's preferences override identical preferences set in any file processed before it.


Setting dev-doc-needed to attract the attention of someone who can document this in the appropriate place.

(Note this document about default preferences for extensions <https://developer.mozilla.org/en-US/docs/Default_Preferences>, although that doesn't seem like the right document for this information, which is targeted to folks building custom Firefox packages, if I correctly understand the use cases of the folks who have been commenting in this bug.)

Note You need to log in before you can comment on or make changes to this bug.