668249 - mozprofile:preferences does not preserve the order of preferences

Status: RESOLVED FIXED

(Testing :: Mozbase, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

while looking into setting enablePrivilege for unittests that require it (for the time being), I found that I need these preferences in order:
user_pref("capability.principal.codebase.p1.granted", "UniversalPreferencesWrite UniversalXPConnect UniversalPreferencesRead");
user_pref("capability.principal.codebase.p1.id", "http://localhost");
user_pref("capability.principal.codebase.p1.subjectName", "");


In addition, these need to be in prefs.js, not user.js.  I can easily work around this, but we should make some of this setup by default with the mozprofile:preferences.

Comment 1

[Jeff Hammel]

prefs.js is doable.....

i wasn't aware that preference order ever mattered.  Really?

Comment 2

[Jeff Hammel]

Attachment: WIP

Found some difficulties going forward while I'll address in other bugs, but here's a WIP that works at the mozprofile level but breaks other things (currently)

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #1)
> i wasn't aware that preference order ever mattered.  Really?

That's news to me too. There should be no requirement to the order of prefs in that file.

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

These prefs need to be in order:
http://hg.mozilla.org/build/talos/file/1128691728d8/base_profile/prefs.js

Otherwise we never set the *.id pref and don't grant access to the value:(  Yes, this sounds silly, but it is the truth for mozilla-central builds.  Whether intended or not, I don't know.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Joel, that really sounds like a bug to me. Can you please file a new bug against the preferences system?

Comment 6

[Jeff Hammel]

I also wonder if this is a bug.

Regardless, in thinking it over I do think mozprofile should preserve the order of preferences.  If, for whatever reason, a consumer feeds in preferences in a certain order, we should keep that order.  (If the consumer gives us a dict, then by nature the order doesn't matter).  There may be legitimate reasons to do this, but in any case it lets us test what we're testing instead of having an implicit abstraction layer that will make things harder to test and debug if things go wrong (including, e.g., looking at the file by hand and going "What happened to this preference that I thought I set?" when it was implicitly overridden).  It is a little more legwork to do this in mozprofile, but I think its worth it.

Comment 7

[Jeff Hammel]

Attachment: preferences are now ordered

this deals with preferences in order in addition to fixing the problem of bug 668676

:jmaher, if you don't want to review, I can pass it on to :harth or :ctalbert.

Also, please file any follow-up bugs if desired

Comment 8

[Heather Arthur [:harth]]

Comment on attachment 543492 [details] [diff] [review]
preferences are now ordered

looks good.

Comment 9

[Jeff Hammel]

pushed to master: https://github.com/mozautomation/mozmill/commit/aa3afa9a5543cd69292b0e4a731dcd88e49af030