QuickFill RFE for the first "Incorrect Key" dialogue?

VERIFIED WONTFIX

Status

()

Toolkit
Form Manager
P3
normal
VERIFIED WONTFIX
19 years ago
9 years ago

People

(Reporter: kevinyen, Assigned: Stephen P. Morse)

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Steve,
Do you think it'd be a good idea to update the first "Incorrect Key" dialogue,
so that the user can re-enter a key right in that dialogue box?

This would minimize the times dialogues pop-up and save the user a logical key
stroke.  So the box might look like:

The QuickFill key you entered is incorrect.  Please re-enter your key if you
want to try again:
                       __________________________

		            [Cancel]	[OK]

-------------
We can fine-tune the wording, but I think the idea would improve the UE.

Also, speaking of UE, I'm communicating UE ideas as quickly as I can.  I wish I
had begun to do so sooner, though, to make it easier on you.  Unfortunately,
client UE team kept on saying that they would get to it (saying this for about 3
months now).  I finally realized that they won't.  In any case, I'm doing what I
can now.

thx,
kevin
(Reporter)

Comment 1

19 years ago
If we did this idea, we'd have to work out the "lockout" threshold.  Is it
best to lockout quickfill:
1. even if the user cancels out of this screen?
2. only if the user enters an incorrect entry on this screen?
3. if there are two, cumulative incorrect entries in any one browser session?

I'm think the third is the best.  What are your thoughts?
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

19 years ago
Why don't we make it really easier for the user and give him the following box
when he enters an incorrect password:

   The key you entered is incorrect.  Try using "..." instead.

Seriously, though, I like Kevin's suggestion.  I'll make this change
immediately.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 3

19 years ago
On second thought, I'm starting to think this is a bad idea.  Although I was
being sarcastic with my example, we are making it easy for someone to hack in.
All sites that I can think of go to a failure screen and force the user to
return back to the login screen for a future attempt.

Besides the anti-hacking protection that this inconvenience provides, it also
makes it clearer to the user as to what is happening.  If I attempt a login and
fail, I get back to a screen that is again asking for a login and I might not
even notice that it is different from the original login screen.  So I'd think
that the system is rejecting logins.

For these reasons I'm closing this out.
(Reporter)

Comment 4

19 years ago
Good points on the hacking protection.  The normal, appropriate user will not
see this screen at all most of the time.  And it's ok to make a nuisance for the
 hackers or tamperers.

Not quite sure what is meant in your second paragraph, but you hacker-targetting
is sufficient in itself for making this "WONTFIX"

Updated

19 years ago
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: paulmac → form.manager
You need to log in before you can comment on or make changes to this bug.