Closed
Bug 247919
Opened 20 years ago
Closed 20 years ago
Add support for wallet.crypto.autocompleteoverride
Categories
(Camino Graveyard :: Preferences, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino0.9
People
(Reporter: stuart.morgan+bugzilla, Assigned: jaas)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
jaas
:
superreview+
|
Details | Diff | Splinter Review |
We should support the Moz pref to ignore autocomplete=off, but currently don't
since we use our own implementation. This may well be too subtle for a GUI pref,
but we should at least honor it as a hidden pref.
Comment 1•20 years ago
|
||
in what cases would we do this? we don't want to allow overriding.
Reporter | ||
Comment 2•20 years ago
|
||
> we don't want to allow overriding.
Um... why not? If a user is finding and changing a hidden pref, they are taking
responsibility for their own actions. Ultimately, the browser is the user's
tool, and if the user feels that keychain provides them with enough security for
their online bank, why should we prevent them from keeping it there (as opposed
to, say, on a stick note).
Besides, some sites abuse autocomplete=off, using it even if there is no serious
security risk to someone else accessing the account. Why should we prevent
knowledgable users from making their own determinations as to which sites are
safe to store in their keychains, rather than allowing any site to do so at
their whim?
(See bug 124065 for the discussion of creating the pref in Netscape.)
Comment 3•20 years ago
|
||
because banks have made it very clear they don't want to give users that power,
at the risk of blocking us. i guess moz does have this hidden pref, though that
amazes me. i'll talk to asa later today.
Comment 4•20 years ago
|
||
after talking with asa, i guess if mozilla does it, it's ok for us to do it too.
i guess we should re-use the prefname even if it's a different system, right?
Status: NEW → ASSIGNED
Target Milestone: --- → Camino1.0
Reporter | ||
Comment 5•20 years ago
|
||
> i guess we should re-use the prefname even if it's a different system, right?
That was my thought, since the effect appears to be exactly the same. Using the
same pref eases transitions from other Moz browsers, makes user-discovery of the
pref more likely, and means one less new pref to add to an already very large list.
Comment 6•20 years ago
|
||
Updated•20 years ago
|
Attachment #153015 -
Flags: review?
Comment 7•20 years ago
|
||
Josh is rewwritting the prefs at the momment so I'm ccing him.
Comment 8•20 years ago
|
||
we should look at this sooner, it doesn't really have much to do with the prefs
rewrite.
Target Milestone: Camino1.0 → Camino0.9
Attachment #153015 -
Flags: review?(joshmoz)
Attachment #153015 -
Flags: review?
Attachment #153015 -
Flags: review?(joshmoz) → review-
Fixes the patch so it applies to latest CVS, also don't bail if pref service is
unavailable. If pref service is unavailable, just use false for the pref. No
reason to bail.
Assignee: pinkerton → joshmoz
Attachment #153015 -
Attachment is obsolete: true
Assignee | ||
Comment 10•20 years ago
|
||
Comment on attachment 164511 [details] [diff] [review]
updated and improved patch v2.0
sr=pinkerton
Attachment #164511 -
Flags: superreview+
Assignee | ||
Comment 11•20 years ago
|
||
landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 12•20 years ago
|
||
Should this be working in 2004110508 (v0.8+)? It doesn't at a site (ba-ca.com)
on which it does using Firefox.
Assignee | ||
Comment 13•20 years ago
|
||
We have issues with frames. It probably won't work on a frames site. I don't
know what the issues are, and it should be a separate bug anyway.
Comment 14•20 years ago
|
||
Frames problem filed as bug 273239.
You need to log in
before you can comment on or make changes to this bug.
Description
•