121287 - Need better user feedback when things go wrong.

Status: VERIFIED WORKSFORME

(MailNews Core :: Security: S/MIME, defect, P2)

Description

[Blu3]

For the last few days, S/MIME has been completely broken.  If you have Digitally
Sign selected under Options, you can't send mail, it pops up with a note asking
you to check your preferences. You need to uncheck Digitally Sign in order to
send the mail, encrypt is simply ignored altogether.

Since 1/20/2002, thing changed for the worse.  Now, you can unselect Digitally
Sign -if- you have not attempted to send the message.  Once you attempt to send
the message, Digitally Sign appears to be unselected but in reality it is still
selected internally.  It is not possible to select/unselect it, it won't change
states anymore.

Due to this, it is now impossible to send this message.

To further compound this, it is impossible to save the message as a file, draft,
template, or Send Later.  The only way to save the data of that email is to cut
and paste it into another file.

In what may be a related case, after failing to send a message, clicking on
File->Close to shutdown messenger causes a crash.  I intend to further verify that.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->PSM S/MIME

Comment 2

[Antonio Lam]

It worked fine for me using 2002-01-23-08 linux trunk build.  I can send a 
signed message to other pesron or myself.

Comment 3

[Stephane Saux]

kai.

Comment 4

[Blu3]

I can assure you that it doesn't work here.  I have a Thawte cert installed and
selected.

Build 2002012408

Comment 5

[Blu3]

Ok, the problem was with my cert CA. By fault of me or moz at the time the cert
was installed, the CA was did not have a trust setting for mail users checked on.

After the CA cert's trust setting was enabled, my personal cert changed from
Verified->false to Verified->true and I was able to send mail properly.

Thanks to Kaie for this.  Now, the issue remains of handling the problem in a
user friendly fashion.

a) let the user unselect the s/mime properties so the email can be sent
b) let the user save the email in file|draft|send later
c) tell the user what is wrong

Comment 6

[Kai Engert (:KaiE:)]

Changing the Summary of this bug. It took me a 20 minutes chat with David to
find out what the real problem was. In order to avoid having to run through this
again, the S/Mime code needs to give much better user feedback and explain what
goes wrong exactly, instead of making the application appear horked.

Comment 7

[Stephane Saux]

S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there
may be some adjustment of the list).

Comment 8

[Stephane Saux]

wfm

Comment 9

[Blu3]

It "WFM" too if the certificate is all proper.  That isn't the problem.  The
problem is that when something -isn't- right, the end user has absolutely no
information at all about how to fix whatever needs fixing.

Look at Kai's comment, #6.  When it takes a developer 20 minutes to figure out
what is wrong, obviously a little clarity is needed.

Again, it isn't a function that doesn't work right, it's a near total lack of
cluing in the user when something isn't configured properly.  In this case, Kai
walked through all of my certificates and had me adjust some settings.

Mozilla -could- have told me ABC needs reviewed with certificate XYZ instead of
giving the erronous feedback that s/mime email couldn't be sent.  Everything is
dandy until you try to send an email and once you do you can't back out of it.

I'm sorry, but "wfm" is really frustrating when there is clearly a situation
that can taken care of.

Comment 10

[Tom Mraz]

I suggest you to open a new bug on this because you are completely correct that
the userfriendliness of the error reporting in S/MIME is really bad but your
original comment in this bug is misleading.
Report here the new bug number.

Comment 11

[Kai Engert (:KaiE:)]

Filed bug 131087.

Comment 12

[John Unruh]

Marking verified, since bug 131087 is open.