version 3 password handling
quantumrider
I noticed that unlike in latest previous version of Firefox 2, in
version 3 I have to select login name or if it is selected tab to
password for the password to appear, previously if I opened a page
which required login for example paypal page both username and
password would already be visible ready to login.
Is this a bug or a feature if it is a feature is there any way to
change this new behaviour to match the old one?
-ark
Justin Dolske
> I noticed that unlike in latest previous version of Firefox 2, in
> version 3 I have to select login name or if it is selected tab to
> password for the password to appear, previously if I opened a page
> which required login for example paypal page both username and
> password would already be visible ready to login.
Paypal's site has:
<input autocomplete="off" type="password">
Firefox 3 won't automatically fill in a login when autocomplete=off is
present, you have to select it manually.
Justin
Philip Chee
If I file a patch under Bug 425145 (See
<https://bugzilla.mozilla.org/show_bug.cgi?id=425145#c5>) would you be
interested in reviewing it?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Put your hard drive to your ear... Can you hear the C: ?
* TagZilla 0.066.6
Mike Beltzner
> If I file a patch under Bug 425145 (See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=425145#c5>) would you be
> interested in reviewing it?
I suppose this is one of those "as the author intended" vs. "user
control" things. While I don't see the problem with an about:config
pref that overrides this, I'm also not precisely sure of the benefit
nor of who would set that preference and why they would do so.
cheers,
mike
Philip Chee
Well, a bunch of SeaMonkey users apparently. And when we manage to
totally kill of wallet/passwordMgr and move to
satchel/nsILoginManager.js it would be a <keyword>regression</keyword>
for SeaMonkey given that this pref currently works in SeaMonkey 1.1.x.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Watch it - you're trying my infinite patience.
* TagZilla 0.066.6
Mike Connor
> On Mon, 16 Jun 2008 08:24:42 -0400, Mike Beltzner wrote:
>
>> On 16-Jun-08, at 6:25 AM, Philip Chee wrote:
>>
>>
>>> If I file a patch under Bug 425145 (See
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=425145#c5>) would you be
>>> interested in reviewing it?
>>>
>> I suppose this is one of those "as the author intended" vs. "user
>> control" things. While I don't see the problem with an about:config
>> pref that overrides this, I'm also not precisely sure of the benefit
>> nor of who would set that preference and why they would do so.
>>
>
> Well, a bunch of SeaMonkey users apparently. And when we manage to
> totally kill of wallet/passwordMgr and move to
> satchel/nsILoginManager.js it would be a <keyword>regression</keyword>
> for SeaMonkey given that this pref currently works in SeaMonkey 1.1.x
>
on toolkit to implement a feature because xpfe-based SeaMonkey had it.
Otherwise we're just reimplementing xpfe in toolkit, which doesn't
really make sense. At all.
-- Mike
Mike Shaver
> That may be the case, but there should absolutely not be a requirement
> on toolkit to implement a feature because xpfe-based SeaMonkey had it.
> Otherwise we're just reimplementing xpfe in toolkit, which doesn't
> really make sense. At all.
I didn't think that the problem with xpfe was the scope of its
capabilities. Surely you don't mean to be saying that any toolkit
with the same capabilities as xpfe is identical to xpfe itself...
Getting SeaMonkey on toolkit is a win for Firefox as well as
SeaMonkey, and I think that minor pref adds are worth it -- especially
for cases like this where there's a legitimate tension between user
control and site preference.
Mike
Justin Dolske
> If I file a patch under Bug 425145 (See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=425145#c5>) would you be
> interested in reviewing it?
I'm not opposed to giving the user more control over the
autocomplete=off nastyness. Although part of the problem is that
sometimes the attribute really is legitimately used to indicate fields
that look like login fields, but are not. A global pref would cause
login manager to fill these in when it really shouldn't. Offhand, that
would seem to make such a pref less useful.
OTOH, as a simple and well-bounded pref that's off by default, it's
probably not a big deal.
Justin
Philip Chee
I would like to write a patch for this, but before I do this, what is
the likelihood that it will be WONTFIXed by the powers that be?
Alternatively is it possible to include a callback or hook so that
SeaMonkey or an extension could use to modify the autocomplete on/off? I
think that there might be an extension or two that would want to turn
this on based on specific sites - possibly leveraging on the site
specific content preferences.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]The trouble with political jokes is: they get elected.
* TagZilla 0.066.6
Justin Dolske
> Alternatively is it possible to include a callback or hook so that
> SeaMonkey or an extension could use to modify the autocomplete on/off?
This is probably the better route, and it's already in place. See bug
439365...
Justin