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)
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.
Reporter | ||
Comment 1•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
There was at least one major change in the preferences backend around the time
of this regression: bug 212222.
Keywords: regression
![]() |
||
Comment 3•21 years ago
|
||
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...
Assignee | ||
Comment 4•21 years ago
|
||
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
Comment 5•21 years ago
|
||
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.
Assignee | ||
Comment 6•21 years ago
|
||
Fixed on trunk with rs=darin
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.6beta
Comment 7•21 years ago
|
||
the ordering i see in camino is now:
all.js
all-camino.js
macprefs.js
this seems wrong to me.
Assignee | ||
Comment 8•21 years ago
|
||
> 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
Comment 9•21 years ago
|
||
so what do i need to name my pref file to ensure it is run last? aaaCamino.js?
Comment 10•21 years ago
|
||
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.
Comment 11•21 years ago
|
||
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.
Assignee | ||
Comment 12•21 years ago
|
||
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
Comment 13•21 years ago
|
||
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?
Assignee | ||
Comment 14•21 years ago
|
||
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?
You need to log in
before you can comment on or make changes to this bug.
Description
•