Closed Bug 21324 Opened 25 years ago Closed 25 years ago

[feature] Mozilla assaults users when asking for a password

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: morse)

References

Details

This broke out of bug 13925.

STEPS TO REPRODUCE
 1. Click on link to a protected page with a fresh Mozilla installation.

WHAT HAPPENS
 1. A dialog box comes up, "Enter user name for <name of realm>", with two text
    fields labelled username and password, and two buttons labelled ok and
    cancel. Enter a username and hit ok.
 2. After that, you get a dialog box explaining that the wallet feature exists,
    and would you like to use it Ok/Cancel.
 3. Then another dialog, would you like to remember the password on _this_ form?
 4. Dialog: Could you give us a key then?
 5. Dialog: Could you repeat that key?

 Even if you hit Cancel at some point, you can still end up with more dialogs:
 4b. Dialog: Would you like to remember this decision for this site?

 WAAAARG! Too many dialogs!

WHAT SHOULD HAPPEN
 There should be ONE dialog box! Not more! Never more than one in a row!

 I am an experienced user, and I got frustrated by the third dialog. I
 can just imagine new users feeling positively intimidated by this
 number of dialog boxes.

 There should be a SINGLE, nice dialog box saying that this site
 requires a password, something like this:

   Please enter your username and password for <name of realm>:
   Username: _____________
   Password: _____________
   [ ] Remember this password in future
   [ ] Encrypt passwords
       Please enter a key to use for encryption: ____________________
       Please confirm this key by reentering it: ____________________

               [( ACCESS SITE )]     [( CANCEL )]

 ...where the last checkbox & key fields only appear if the user has
 not yet given a key. Please don't use Ok/Cancel (or even Yes/No)
 dialogs for cases where a checkbox in a previous dialog would
 suffice! And definitely don't bring up dialog boxes telling me that
 there is a feature, just offer the feature anyway! (Yes, this even
 applies to 'only once' dialogs -- on the system here, for example, we
 cannot save our settings so we would get the dialog every time we used
 the program, not just once.) Note that the "remember password" check
 box should probably default to whatever the user last said to that
 checkbox, not always to off or always to on.


cc'ing Matthew Thomas, who is sure to see something wrong with the above (hey,
I'm no interface expert!) and who is likely to know of any bugs of which this
is a duplicate.

See also:
   bug 13228 Yes/No/Never dialog needed
   bug 13022 Wallet UE changes
   bug 16686 Request Database key before "Remember password" dialog
   bug 19935 User-name/password and wallet dialogs should be merged (RES/DUP)
   bug 13925 Intrusive alerts advertising features.

Additional comments from trudelle@netscape.com on parent bug 13925:
> Each case should be a separate bug.  This latest case should be high
> severity, I think we will lose users if we bludgeon them like that.
[cc:ing Paulmac --- wallet QA. Paulmac, please add your friends as you deem
appropriate. ;-]
adding steve morse
You're not trying to suggest that I'm an interface *expert*, are you? :-)

You have to balance the annoyance of multiple dialogs, with the confusion caused
by adding a heap of (usually disabled) controls to a dialog which -- on the
basic level -- is just asking for a username and password.

The password encryption setup is something that will only be done once, so I
think it's quite appropriate to have it in its own dialog. But a dialog solely
for the purposes of asking you if you want to use the Wallet is a bit ... odd.
If you want Mozilla to remember the password, you want Mozilla to remember
the password. That the Wallet is used to do this is not really important to the
user.

So:

+----------------------------------------------+
|[] Authentication required :::::::::::::::::::|
+----------------------------------------------+
| /`___ Please enter username and password for |
| \/""  {realm} at {server}:                   |
|                  __________________________  |
|       _Username [__________________________] |
|       _Password [__________________________] |
|                                              |
|       [ ] _Remember this password            |
|----------------------------------------------|
|( Help )                ( Cancel ) (( Enter ))|
+----------------------------------------------+

The authentication is then sent to the server, so the page starts loading in the
background. While that's happening, if this is the first time you have ever
chosen `Remember this password', you get:

+-------------------------------------------------+
|[] Wallet :::::::::::::::::::::::::::::::::::::::|
+-------------------------------------------------+
| This is the first time you have asked for a     |
| username and password to be remembered for this |
| profile. If you wish, you may use a single      |
| `key' to encrypt all your stored usernames and  |
| passwords.                                      |
|                                                 |
| [*] _Use a key to encrypt my usernames and      |
|     passwords                                   |
|                   ____________________________  |
|     _Enter key:  [____________________________] |
|     _Verify key: [____________________________] |
|     For hints on choosing a key, select `Help'. |
|                                                 |
|-------------------------------------------------|
|( Help )                           (( Continue ))|
+-------------------------------------------------+

That's from five dialogs down to two, with the second one only ever appearing
once. Hope this helps ...
Assignee: shuang → morse
Let me add my two cents here.

Dialogs 4 and 5 are indeed supposed to be one dialog and if you look at the code
in singsign.cpp you will see that.  However the single dialog with two password
fields does not yet exist (that's on davidm's plate) and so temporarily we are
simulating that with two back-to-back dialogs.

Dialog 2 is a one-time only dialog (that's once for the life of the browser) and
is for discoverability purposes.  Since the pref to pre-fill passwords is off by
default, the user would never know to turn it on and so nobody would ever use
it.  If the user clicks affirmative to this dialog, the feature is enabled.  If
the pref was on by default this dialog would not be necessary.  I'd be open to
considering changing the default and dropping dialog 2 completely.

Dialog 3 is important and is not redundant with 2.  Dialog 2 was a one-time
dialog asking if you wanted the feature enabled.  If the feature is
disabled, you never get asked dialog 3.  If the feature is enabled, then
each time you submit a form containing a password you are asked if you
want the username/password to be saved.  It is necessary to ask this each time
rather than save automatically in order to prevent having your password saved
withoug your knowledge when you were using someone elses machine.

Botton line: When dialogs 4 and 5 get coalesced (as they will) we will be down
to 4 dialogs.  If we change the pref (up for debate), we will be down to three
dialogs.  Of those three, dialog 4 occurs only once per browser session.

Finally, unless someone objects, I'm assigning this bug to myself.
Status: NEW → ASSIGNED
Target Milestone: M14
Bug 21533 has just been opened -- it's a request for the dialog containing two
password fields.
I don't care if Dialog 2 *is* a one-time dialog, it's still completely
redundant. To repeat my earlier statement: If you ever want Mozilla to remember
a password (and indicate this using the checkbox), *by implication* you want
Mozilla to use the Wallet. So a `do you want to enable the Wallet' dialog is
just gratuitous clickage.

And the whole of dialog 3 could still be replaced by the single checkbox in
dialog 1, so making a whole new dialog for that is just silly.
There's some confusion here.  In particular your statement:

     If you ever want Mozilla to remember a password (and indicate
     this using the checkbox), *by implication* you want Mozilla
     to use the Wallet.

First, your use of "wallet" is misleading here.  The word "wallet" is never used
in any of these dialogs.  Furthermore, the feature discussed in this bug report
is not "wallet" but rather "single signon".

I don't mean to be splitting hairs of semantics, but it's your use of the term
wallet that I'm confused about.  We never ask the user if he wants to use wallet
(presumably as opposed to some other technology) when he says he wants to save
his password.  Rather the dialogs go as follows:

dialog 2: This is saying in effect "We have this new feature for saving
passwords that you might not discover on your own.  So we are telling you about
it this one time and asking if you if you want this feature enabled.  If you
don't enable it, we will not bother you again.  But if you do, then every time
you submit a form containing a password, we will ask you if you want that
password saved."

dialog 3:  This is the dialog that appears when the user submits a form
containing a password.  It is saying in effect "Since you told us that you want
to save passwords, we are now asking if you want the password on this particular
form saved.  We have to ask you this every time you save a form so that no
unscrupulous person can enable this feature behind your back and capture all
your passwords without your knowledge."
In answer to your other comment:

   And the whole of dialog 3 could still be replaced by the single
   checkbox in dialog 1

That might be true for password dialogs that are generated by the browser (such
as http authentication and ftp authentication) but its not true in general.
Many of the password dialogs encountered are for logins to particular services
on the web.  These dialogs are put up by the website itself and are not under
our control so we can't go adding checkboxes to them.
The one change I think we should seriously consider is adding a checkbox rather
than using the Yes/No/Never dialog. Most of the other dialogs are on shot dialogs
so the efficiency of them is not critical. But getting asked the question ever
time I go to a site with a new (http/ftp) authentication dialog is real annoying.
The Yes/No/Never dialog will still be needed for forms and webpage logins. An
alternative would to provide a preference to always save the passwords but I
haven't thought through all the implications of that yet.  Perhaps when the UI is
refined so the dialogs pop up instantly and can be dismissed with a key stroke,
they will not be so bad. Right now they are very disruptive to my browsing
experience.
Yes, it's worth considering doing browser-generated authentications (ftp, http,
mailnews, composer) differently from server-generated login forms -- i.e., the
checkbox on the browser authentications, a yes/no/never dialog following the
server logins.

But we must not have a pref to automatically save passwords.  That's already
been shot down by our security people because it leads to the following
very-real attack.  The owner of a cyber-cafe sets his pref to always save.
Unsuspecting users then use his machine and have no idea that their
username/passwords are being saved.  At the end of the day the owner harvests
all the username/passwords that he has collected for that day.
I don't think that is much ( any) security. Any decent coder will in a half hour
be able to write up a version of wallet.dll which will do the same thing.  Or
skip the wallet entirely and just save ever form that is submitted.  Given that
you could gain credit card numbers by doing this, I would think it would be a lot
more profitable. If someone wants to be evil and they control access to the
machine, I think the user is screwed.
I used exactly the same arguments you are using when this issue of security
first surfaced.  In fact, I went a step further and said that an evil cyber-cafe
owner could just plant a keyboard-capture program on his machine and then look
over the log at the end of the day.

The counter-argument was that the person would need to possess some knowledge in
order to do any of this.  But if we included an option in the browser that makes
it easy for him, then any idiot could do this attack.

For my own personal use, I would love to have such a preference and would always
set it to save automatically.  But I can see the validity of the argument
against having the pref.
I still have two things against the 'one off' dialogs. First, they are not
always 'one off'. As I pointed out at the start of this bug, on the system here
we cannot save our settings so we get the dialog every time we use the program,
not just once. Second, the first time the feature is used is the _very_ time you
want to make sure the user is happy -- by "bludgeoning" our users with two or
more dialogs in a row we will achieve the opposite effect. (I see this every day
in IE5, too. Very irritating.)

We could solve all this by building a single dialog box which includes only the
components required for that particular occasion:

 1. Include username and password fields along with a label if this is not a web
    form (e.g., if it is HTTP or FTP authentication). If these fields are
    present, then the title of the dialog should be something like
    "Authentication Required" and the default button should be something like
    "Enter", otherwise the caption should be something like "Single Signon" and
    the default button "Continue" (and the cancel button can be removed).

 2. If the user has not selected "never remember any passwords" or if we
    included the username/password fields above, then include a set of radio
    buttons labelled something like "Remember this password", "Don't remember
    this password" and "Never remember any passwords". Check the one that the
    user checked last time we displayed this, defaulting to "Don't..." for the
    first time. If these radio buttons are used, then include a label that reads
    something like "Mozilla is able to remember this password so that you do not
    need to enter it again in the future.".

 3. If the 'username and password remembering' feature has not yet been given a
    key, then include a check box and two fields for setting the key. (Note.
    This should only be actually enabled if the "Remember this password" option
    is selected, otherwise it makes no sense and would not be used.) If these
    fields are included then supplement the label from point 2 with something
    along the lines of "Your usernames and passwords can be encrypted to reduce
    the risk that someone can steal them from your computer.".

 4. If the above means that no fields are displayed, then skip the dialog box
    altogether. (This will only occur if it is a web form, and the user has
    already seen this dialog, and "never remember any passwords" has been
    checked.)

Thus the most complicated case would look like this:

   +-------------------------------------------------+
   |[?] Authentication required :::::::::::::::::::::|
   +-------------------------------------------------+
   | /\___ Please enter username and password for    |
   | \/ "" {realm} at {server}:                      |
   |                  __________________________     |
   |       _Username [__________________________]    |
   |       _Password [__________________________]    |
   |                                                 |
   | Mozilla is able to remember this password so    |
   | that you do not need to enter it again in       |
   | the future. Your usernames and passwords can    |
   | be encrypted to reduce the risk that someone    |
   | can steal them from your computer.              |
   |                                                 |
   | ( ) _Remember this password                     |
   | (*) _Don't remember this password               |
   | ( ) _Never remember any passwords               |
   |                                                 |
   | [x] Use a _key to encrypt my usernames and      |
   |     passwords      ___________________________  |
   |      _Enter key:  [___________________________] |
   |      _Verify key: [___________________________] |
   |     For hints on choosing a key, select `Help'. |
   |                                                 |
   |-------------------------------------------------|
   | ( Help )                 ( Cancel ) (( Enter )) |
   +-------------------------------------------------+

...and the most number of dialog boxes ever shown would be one. (This would also
make the idea of "what am I cancelling!?" a lot easier to sort out -- currently
it is not always clear.)

The "do you wish to remember this password" dialog for web forms becomes as
follows (note that only one dialog comes up -- there is no "hey, look how cool
we are" dialog box introducing the feature in the first place):

   +-------------------------------------------------+
   |[?] Single Signon :::::::::::::::::::::::::::::::|
   +-------------------------------------------------+
   |                                                 |
   | Mozilla is able to remember this password so    |
   | that you do not need to enter it again in       |
   | the future.                                     |
   |                                                 |
   | (*) _Remember this password                     |
   | ( ) _Don't remember this password               |
   | ( ) _Never remember any passwords               |
   |                                                 |
   |-------------------------------------------------|
   | ( Help )                         (( Continue )) |
   +-------------------------------------------------+

If the user chooses "Never..." then no dialog will ever come up again for that
case, as if the user had chosen "No" to the current introductory dialog box.

Finally, here is what the HTTP authentication dialog would look like, once the
feature has already been used:

   +-------------------------------------------------+
   |[?] Authentication required :::::::::::::::::::::|
   +-------------------------------------------------+
   | /\___ Please enter username and password for    |
   | \/ "" {realm} at {server}:                      |
   |                  __________________________     |
   |       _Username [__________________________]    |
   |       _Password [__________________________]    |
   |                                                 |
   | Mozilla is able to remember this password so    |
   | that you do not need to enter it again in       |
   | the future.                                     |
   |                                                 |
   | (*) _Remember this password                     |
   | ( ) _Don't remember this password               |
   | ( ) _Never remember any passwords               |
   |                                                 |
   |-------------------------------------------------|
   | ( Help )                 ( Cancel ) (( Enter )) |
   +-------------------------------------------------+

This is down from two dialogs which is what the current plan has been.

(Implementing this should not be _too_ difficult with classes and the contextual
selectors of CSS -- you could, say, give the xul:window element of the dialog
box a class of "auth" if we need authentication elements, "remember" if we need
the remember radio buttons, and "key" if we need the key fields, and then wrap
the fields in <div> (or equivalent) containers with classes themselves, then
use some CSS such as:

   div.auth { display: none; }
   window.auth div.auth { display: block; }

   div.remember { display: none; }
   window.remember div.remember { display: block; }

...or whatever. A little JS glue, and...)
If you are willing to to a largely fixed text dialog then it is easy to do all
sorts of dialogs tailer to a specific task. That's not the path mozilla is using
for these types of things. Instead we customize generic dialogs. At the time the
password dialog pops up, the dialog has no concept ( nor should it) of what type
of dialog ( http auth, mail password, ...) it is.
Whiteboard: (py8ieh:may try to write some XUL for the suggested dialog)
I think this may be one case (or rather, a set of cases) where a more specific
dialog is needed. It really is not user-friendly to be giving more than one
dialog box in a row.

How difficult would using the more specific dialog box I suggest above, in
these particular cases, be? I suppose I could have a go at designing the dialog
box itself, I should have a few minutes free next week -- the real problem will
probably be grabbing the replies out of the dialog and back into the code.
I agree with all the arguments presented here about reducing the number of
dialogs and that the initial set of five dialogs was unacceptable.  But the
other extreme of getting down to one dialog can be equally bad.  In particular,
I would find the first of the three dialogs presented abjove by py8ieh to be
quite intimidating.  I think that if we get it down to one dialog for
browser-generated forms, two for server-generated forms, and one more dialog for
the first usage of the feature in the browser session, this would be quite
acceptable.

So here are the dialogs that I propose:

A. Browser-generated forms:

  dialog 1:

    Please enter username and password for ...

      Username ____________
      Password ____________

      [x] Save username and password for future use

         [CANCEL]  [OK]

  dialog 2a: (only if this is the first time database is ever accessed)

    Select a key for your database (leave blank if you don't want to use a key)
      enter key _________________
      enter again for verification _______________

          [CANCEL]  [OK]

  dialog 2b: (only if this is first time database is accessed in this session
              and dialog 2a has not been issued in this session)

   Enter your database key _________

          [CANCEL]  [OK]

B. Server Generated Form

   dialog 1:

      dished up by server -- asks for username and password

   dialog2:

      Save username and password at this site for future use?

           [YES]   [NO]    [NEVER FOR THIS SITE]  [DISABLE THIS FEATURE]

  dialog 3a: (only if this is the first time database is ever accessed)

    Select a key for your database (leave blank if you don't want to use a key)
      enter key _________________
      enter again for verification _______________

          [CANCEL]  [OK]

  dialog 3b: (only if this is first time database is accessed in this session
             and dialog 3a has not been issued in this session)

   Enter your database key _________

          [CANCEL]  [OK]
And of course dialogs 2a/2b for browser-generated forms and 3a/3b for
server-generated forms would not be presented if the user indicated in the
previous dialog that he didn't want to save the current info.
I forgot to mention that trying to write your own xul dialog box to do any of
these dialogs would not be a good idea.  Right now we have all these types of
dialogs centralized by using davidm's dialog module.  That way they will all
have the same look and feel.  Furthermore, general dialog problems can be fixed
in one place (recall the fiasco we had when I had separate Yes/No dialogs from
david's OK/Cancel ones and he fixed his to be thread-safe, thereby leaving mine
hight and dry).

Furthermore, the dialogs themelves are the least of the changes involved here --
the bulk of the work will be in the c++ coding that processes the dialogs.  So I
would discourage py9ieh from doing what he is proposing in the Status
Whiteboard.  But if he is volunteering to create the general dialogs in davidm's
module and to make the coding changes in my module to use those general dialogs,
that's a different story.
1. Apologies for confusing single sign-on with the Wallet. I've been thinking
   about the Wallet too much lately.

2. I just don't understand Morse's comment about server-side logins, `These
   dialogs are put up by the website itself and are not under our control so we
   can't go adding checkboxes to them'. Uh ... Why not? It's not as if the Web
   server is writing the dialog pixels to the screen, is it? And it's not as if
   Mozilla is completely oblivious to the data entered in the dialog.

2. py8ieh's morphing behemoth dialogs seem over the top to me.

3. The cyber-cafe risk is *solved* by the checkbox. If you have a checkbox on
   the login dialog (and the checkbox is always off unless the user checks it
   for a specific password), it's crystal clear to the user whether the login
   will be remembered or not. As additional protection, you could use two
   checkboxes in a login dialog,

   [ ] Remember this login until you exit Mozilla
   [ ] Remember permanently

   where the checkboxes are mutually exclusive.

If you have a checkbox advertising the feature, you don't need a dialog to
advertise the feature. And if you have a checkbox for the feature, you don't
have an annoying dialog asking you if you want to use it this time, therefore
you don't need a dialog asking you if you want the annoying dialog to appear in
the future ...

So, I see no reason in this discussion to change my original design suggestion
-- except to change the `Wallet' window title to `Encrypt stored logins?'.
2: the 'server side login dialogs' are actual web forms, as opposed to dialogs.
So no, we can't add the check boxes to them. That would be changing the web
content, which is not at all obvious.
py8ieh's answer to #2 is correct -- these are website content and we don't want
to go redesigning such content on the fly.  Each website would put up the dialog
in its own unique way so it would not at all be obvious as to how to incorporate
the checkbox in a generic way that would be satisfactory for all such sites.
Changing website content is not at all a good idea.

But I admire mpt's persistence in trying to unify things between
server-generated and client-generated login forms, thereby solving the
cyber-cafe attack.  However, I don't believe we can do it in a satisfactory way.
Ok, thanks for the explanation of what `server-side login dialogs' actually
were. That's a separate security/bogosity problem, and outside the scope of this
bug.
*** Bug 20713 has been marked as a duplicate of this bug. ***
Summary: Mozilla assaults users when asking for a password → [feature]Mozilla assaults users when asking for a password
I have been on vaction so sorry for the late response. I agree that we don't want
to be modifing the webpage logins. But having a single sign on bar that we add to
all those web pages so for example when we realize that the web page is a login
one, we could add a toolbar with the needed UI elements. On the bright side you
could get rid of a couple of dialogs ( I would have a popup to select a user,
check boxes to remember sites, never ask again ). This would be a decent amount
of work and might not be as intuitive as I would expect.
	I don't think adding a dialog to remember passwords on a per session basis
adds any value. I would imagine that most people don't switch between
authenticated sites multiple times during the same cyber cafe session. I think
the checkbox gives the same safety ( we should be filling in dialog, the user can
see the checkbox before hitting OK ) with less UI clutter.
	In steve's list of dialogs, if we want to do A1, that decision should be made
real soon before I leave xpapps.
	One thing I just thought about is what about having the user configure the
database key when they create a profile. The advantage is it would move the point
at which the user creates the database key to the same place where they enter
other "personal" information. Similiary we could ask for the password right after
selecting the profile. The downsides that spring to mind are that the user might
end up doing unneeded work, they might not understand what they are entering a
password for, and they might get a false sense of security if they conclude that
the password protects their profile.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I implemented a universal dialog from which I can custom-build various dialogs.
Some of the special dialogs required here are special cases of the universal
dialog.  So I have been able to build them with the universal dialog and have
now reduced the number of dialogs considerably.

It is as described in my message of 12-16 at 00:36 except that we still have the
initial dialog asking the user if he wants to have the single-singon feature
enabled.  As I described above (12-12 at 10:04 in second paragraph), we can
eliminate that dialog if we change the default value of the single-signon pref
to be initially enabled.  But the decision has not been made.  If anyone still
objects to that initial one-time dialog, then please open up a new bug report
(this one is too cluttered) requesting that the default value of the pref be
changed.
QA Contact: elig → paulmac
My feeling is that this is a wallet-specific issue, rather than a general UI
issue. QA Assigning to paulmac for verification.
morse: We still get the "do you wish to remember the password for this site"
dialog, instead of using a check box. So the user is still getting three
dialogs the first time, and two thereafter.

Is this as designed, or did you intend to use a check box? You say that it is
"as described in my message of 12-16 at 00:36", but in that message you use a
check box, so I guess that this is still a bug. Shall I reopen?
Status: RESOLVED → REOPENED
Target Milestone: M14 → M13
You're right, I forgot to put it in the checkbox for the case of browser
generated forms.  I also didn't get the buttons right on the
yes/no/never/disable dialog box for server-generated forms.  So I'm reopening.

I did change the default to enabled so that initial discovery dialog is no
longer present.

Copying Kevin Yen because we had some discussions this week on whether to have
the fourth button or not.  At that time we concluded we wouldn't have the
"disable" button but now I'm inclined to think that we should have it.  It's
crucial that we get the wording correct on these buttons.  Currently the wording
is yes/never/no.  I think the wording as proposed in this report of
yes/no/never-for-this-site/disable-this-feature would be better.  Is this too
much text to put in buttons?  Should I stay with just the three buttons?  Any
comments?
Status: REOPENED → ASSIGNED
Resolution: FIXED → ---
OK, I have the changes ready to be checked in that add the checkbox.  All I need
is a code review.  Any volunteers.
Summary: [feature]Mozilla assaults users when asking for a password → [feature] Mozilla assaults users when asking for a password
Whiteboard: (py8ieh:may try to write some XUL for the suggested dialog)
morse: I would agree that long button labels are better.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Fix for checkbox has been checked in.  One less dialog.  Now there are two
dialogs for server-generated forms and one for browser-generated ones.  And
there is no extra penalty on the very first occurence.

Did not change the button labels.  If anybody feels strongly about that, open a
new bug report.  Closing this one out as fixed.
QA Contact: paulmac → sairuh
Oops, I summarized that wrong.  There is no extra dialog on the very first usage
ever (i.e., no dialog asking if you want the feature enabled).  But there is an
extra dialog on the first usage per session that asks you for your database key.
no longer feel assaulted w/too many dialogs when using single signon/autofill.
:-)
Status: RESOLVED → VERIFIED
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.