Closed Bug 224840 Opened 21 years ago Closed 21 years ago

security.warn_submit_insecure defaults to true in Firebird

Categories

(Core :: Preferences: Backend, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.6beta

People

(Reporter: jruderman, Assigned: benjamin)

References

Details

(Keywords: regression)

1. Create a new profile -OR- run a Firebird build from before 11/03. 2. Run a Firebird build from 11/04 or 11/05. 3. Submit a form. Result: insecure form submission warning dialog appears. This never happened in Firebird builds older than 11/03, and it seems to be due to a change in the preferences backend, not a change in Firebird, so I doubt it was intentional.
You can also see that security.warn_submit_insecure defaults to true in about:config. Maybe the order of loading all.js and security.js (?) was reversed? They have conflicting values for this pref.
There was at least one major change in the preferences backend around the time of this regression: bug 212222.
Keywords: regression
It does look like the ordering changed, yes. The files used to be loaded in reverse alphabetical order; now they are loaded in alphabetical order. On the other hand, relying on any particular sort order for pref files that all live in the same dir seems very broken to me. The prefservice apis do not guarantee any particular load order...
ick, I didn't read the sort code carefully enough. Does this mean that the old code read 1) security.js 2) mailnews.js 3) all.js This seems backwards to me, but the point was to keep backwards compatibility, so I guess I should make the one-line change. Darin... r/sr for reversing the sort order? --BDS
Assignee: prefs → bsmedberg
Well, given what the issue is, and the issue is different preferences in different files so the load order is significant, should not the load order be such that application specific prefs files (like mailnes.js) override things in all.js? If this makes it non-backwards compatable I don't have an issue with this if the old order appears to be wrong.
Fixed on trunk with rs=darin
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.6beta
the ordering i see in camino is now: all.js all-camino.js macprefs.js this seems wrong to me.
> this seems wrong to me. This is in fact the "correct" ordering, historically, because macprefs is a "special file" to be parsed after everything else. --BDS
so what do i need to name my pref file to ensure it is run last? aaaCamino.js?
hrm, you're right, those are hardcoded to be last. ugh, i guess i'll have to override them in code, which seems to defeat the purpose. oh well.
is it our design that {platform}prefs.js cannot be overridden except by code? That seems suboptimal and leaves it so that the user cannot then override in their local profile prefs.
Pinkerton: Local profile prefs do override all the default prefs. And the platform-* pref files are disappearing soon (when 1.7a opens) see bug 224578. So that you will have "tiers" of prefs: embedding (GRE) default prefs application default prefs profile (user) prefs (you don't have to use the GRE to make use of the embedding prefs tier). --BDS
but currently i cannot override anything that is in platform prefs as an app developer unless i hardcode the pref in code at startup. then the user can't override it (because i've hardcoded it in code). does that make sense?
I agree that it is an unpleasant behavior... but what can I do about it? I need to maintain backwards compatibility with this broken behavior. I'm getting rid of this whole problem in bug 224578 anyway, can you wait for that to land?
Depends on: 224578
QA Contact: benc
You need to log in before you can comment on or make changes to this bug.