Enigmail sometimes fails to encrypt messages and immediately sends them!
I'm just messing around with it now in an email discussion with a friend with PGP capability.
I think this might be a UI bug, in that no checkmark ever appears in the OpenPGP context menu(1) when 'Encrypt Message' is clicked. Thus the user is fooled into thinking it didn't work, but perhaps the checkmark is invisible but the flag is properly set.
Since my last Tenfourfox update I've noted some bugs in the OS X menus produced by an add-on; I don't think the add-on is anywhere near close enough to the OS to cause display bugs in OS X menus, because what happens is selection of a context menu will "bleed through" (down the z-index or "stack" of menus) to a context menu behind it. The point being, perhaps some basic UI bugs have crept into code from Tenfourfox which you are using in Tenfourbird?
(1) By "OpenPGP context menu" I mean, in the Write window, the menu from the little triangle near 'OpenPGP' which displays an OS X menu, and NOT the OpenPGP button to the triangle's left which opens a separate pop-up dialog equivalent to (we hope) the OS X menu. These UI elements contain 'Encrypt Message', 'Sign Message' and so forth.
Please see http://tenfourfox.tenderapp.com/discussions/problems/739-mouseover-highlight-in-multi-stage-context-menu-bleeds-through for the Tenfourfox / add-on bug which is very likely unrelated, but is a menu UI bug in a related project.
t_mrc-ct Thank you for reporting bug. I could reproduce this bug.
As you thought, this is UI (context menu) bug. But I still not find out cause of this bug.
I am planning to make simple testcase addon which could run on Tenfourbird and TenFourFox. It may help debugging of this bug.
Regards.
t_mrc-ct I uploaded the test add-on. (checkmark-test20140317.xpi)
On checked window, you can change every menuitem's checked state.
But on not checked window, you can (usually) not change menuitem of toolbarbutton's checked state. (but somtimes you can change...)
This bug happens on toolbarbutton's menuitem only. menuitem of other XUL elements are working properly.
I do not know the cause at all yet...
Regards.
t_mrc-ct I still not find out cause of this bug. But I found workaround of this bug.
At first, I thought this is toolbarbutton specific bug. But now it becomes clear that this bug happen on almost all menus if container element's text-shadow are changed when menu is opened.
But there are workarounds:
I don't know how these affected to prevent this bug.
I uploaded new add-on which reproduce these behavior.
Usage (reproduce bug):
Usage (preventing this bug):
(Installation steps are skipped)
Next release (Tenfourbird v24.5.0) will be contain workaround of this bug. It will fix this Enigmail bug.
But unfortunately, some add-ons that have its own stylesheet changes text-shadow will be still affected by this bug.
Thanks.
Another workaround:
-The following extension provides delayed send capability through SEND LATER button -Messages are stored in OutBox until GET/SEND is pressed -Outgoing messages can be examined with the message preview pane (f8 key) -This is a useful tool for diagnosing mail send problems
https://addons.mozilla.org/en-US/thunderbird/addon/magicslr/ http://www.thunderbird-mail.de/wiki/MagicSLR_(english)
Tenfourbird
I have only experienced this bug several times today, so it may be hard to reproduce. It may also have to do with attaching files, as I attached a file the first time it happened and did not select PGP-MIME, rather I selected 'encrypt and sign all separately.' I did not see the usual change of my message text to a PGP blob and did not see '.sig' files appear in the attachments pane as I am used to seeing. Then the message sent immediately, and the recipient verified all content was unencrypted!!!
I tried a couple more times, with and without attachments, with PGP-MIME instead, and mails also immediately sent unencrypted!
I can try to reproduce this for you if you give me some ideas. I will reboot my machine, restart Tenfourbird and see if it happens again.
OS X 10.5.8, PPC7450. I am setting the severity to 9 on this ticket because it could be a huge disaster for encryption users.