Closed Bug 20336 Opened 25 years ago Closed 21 years ago

Ctrl-Enter should send the message only if there is pref to turn it off


(MailNews Core :: Composition, defect, P2)



(Not tracked)



(Reporter: rzach, Assigned: sspitzer)



(Keywords: helpwanted, polish, Whiteboard: [nsbeta1+]blocked by bug 50255,[correctness],PDT-)


(1 file)

As in Navigator, 4.x, pressing Alt-Enter in the message compose window should
send the message, Alt-Shift-Enter send it later.

Linux build 1999.11.29.08
QA Contact: lchiang → esther
Target Milestone: M14
Target Milestone: M14 → M15
Note that it's CTRL-Enter on Windows and CMD-Enter on Mac. Would like to have
this for B1, but wouldn't hold for it.
Alt-Enter now seems to attempt to send the message, but causes Mozilla to hang
(Linux build 2000.02.11.11).
Does clicking the Send button cause it to hang?
No, send button is fine.
After I hit Alt-Enter, I get this in the console:

we don't handle eBorderStyle_close yet... please fix me
-------- BOX IS ROOT --------
onload top.composeWindow: [object Window]
onload toAddress:

Then Mozilla becomes unresponsive and has to be killed.
I'm going to modify the summary and nominate for beta since the hang can result 
in data loss of the compose window.
Keywords: beta1
Summary: Alt-Enter should send message → Alt-Enter to send message causes a hang
Putting on the PDT+ radar for t hang and beta1.  But discarding the key binding
is perfectly acceptable for beta.
Whiteboard: [PDT+]
Btw, I think we're moving to Ctrl for shortcuts, so it should probably be
Ctrl-Enter anyway.
On Linux build 2000.02.14.09 I don't hang anymore.  Could you verify, and then
either make this into the shortcut RFE or resolve and file a new bug (or tell me
what to do)?
Why don't we just turn this bug into switching to ctrl-enter then (where did you 
hear about the ctrl key?)  Thanks.
In bug 23575 german writes: "We had collectively decided earlier (after a
newsgroup poll and discussion) to move away from Alt as shortcut and leave this
for menmonics only. We decided to use Ctrl as default shortcut qualifier key for
Linux et al. This is the state it should be in for beta1."  Assume since we're
talking about shortcut for Edit | Send, it should now be Ctrl-Enter. CC german,
I don't understand why alt/ctrl-enter causes the application to crash. Atl-enter 
is not yet binded to Send.

As zach doesn crash anymore, I remove the [PDT+] status and change back the 
summary to "Ctrl-Enter should send the message". If PDT team agree, we should 
remove the keyword beta1
Summary: Alt-Enter to send message causes a hang → Ctrl-Enter should send the message
Whiteboard: [PDT+]
Putting on PDT+- radar for beta1.  Would not hold beta, can release note if 
Keywords: relnote
Whiteboard: [PDT-]
Adding a few interested people to the cc list.

I would like to see this bug resolved as WONTFIX since I often see reports of 
users who press enter/return and inadvertently also press control.  This makes 
them look stupid when they've sent a message that they didn't finish.

If we really need a keybinding for this, how about a 3-key binding or something a 
little less likely to be pressed while typing?
I miss having a "send" binding and use control-return heavily in 4.x, but I
agree with Kathy that it's unintuitive.  I'd like to see this functionality
bound to some other key -- not a 3-key sequence, just something a little less
unintuitive than control-return.

I hesitate to suggest one since I don't know what's available.  Do we have a
spec anywhere for key bindings?
This is my most hated keyboard shortcut. I can't tell you how many times I've 
fumbled on the keyboard, and sent a message by mistake. Please either kill this 
shortcut, or put up a confirmation dialog before sending.
cc: for input.
removing relnote keyword.  Will include a general statement in mailnews release
notes something like "not all keyboard shortcuts are implemented, please rely on
relative menu or toolbar items".
Keywords: relnote
Ctrl+Enter seems to me to be about as intuitive as you can get. But if there 
really are some people who type it by mistake (is there some keyboard layout I 
don't know about where Ctrl and Enter are next to each other?), then perhaps this 
is a good case for an optional confirmation dialog.

Since the keyboard shortcut itself involves the Enter key, the default action for 
the confirmation dialog should probably be Cancel. This would prevent problems 
where the user presses Ctrl+Enter, sees a dialog come up, thinks `oh, whoops, I 
actually meant to press Shift+Enter' (or whatever), and then does the usual human 
thing by going ahead and pressing Shift+Enter (or whatever) -- thereby dismissing 
the dialog and sending the message.
Keywords: 4xp
OS: Linux → All
Hardware: PC → All
Nooo, please, not a confirmation dialog!  The whole point of having a keybinding
here is as a "quick send without having to use the mouse".  If I then have to do
something else (usually involving moving from the keyboard to the mouse) this is
no longer a win over clicking on the toolbar.

A better solution would be to use a different binding, one which users don't
tend to hit by accident.  I'd suggest one if I knew of where to find the
existing bindings, in order to look for one that isn't already spoken for.
* Some e-mail/Usenet clients, such as MT NewsWatcher for example, have an
  optional confirmation dialog for sending messages already. It's useful as a
  sanity checker, not just as a way of making sure that you didn't hit the Send
  key combination by accident.

* Why should dealing with a simple confirmation dialog involve using the mouse?
  It would be Ctrl+Enter to bring up the dialog, then Tab, then Enter.

* You're going to have the problem with accidentally hitting the key-binding
  occasionally no matter which key-binding you choose.

* Ask Lake if you want a list of the current bindings. They haven't been
  published anywhere yet AFAIK.
* It involves the mouse because when the dialog comes up, the focus isn't in it,
so hitting return will go to the wrong window.  You obviously use a
click-to-type focus model; not everyone does.  This is especially true in
mozilla, where we don't mark our dialogs as transient so even Linux window
managers which are smart enough to put focus in transient windows don't know to
do so in mozilla.

* I have never accidentally hit the alt-return binding, in three years of using
4.x. Which is not to be construed as an argument that I think it's a good choice
for the binding, just that lots of people are good with keyboard control and bad
with mouse control, just as some people are the other way around.
How about a pref? ;)
akkana: Well, that's a problem with Mozilla's dialog windows on X in general, 
then; it's not a problem which should spill over into deciding whether a 
confirmation dialog is a good idea or not in this particular case. (And, like I 
said, the dialog should be optional, so people who don't have a problem with the 
key-binding can have the confirmation dialog turned off.)

We shouldn't make Mozilla's UI worse, XP, just because some X window managers are 
clueless. If you followed that argument to it's logical conclusion, Mozilla could 
never have any confirmation dialogs at all.
I would like a pref as well. 
I also wouldn't mind a dialog asking if I want
to send. If you want Ctrl+Enter because you like the keyboard interface, you
just hit Enter for the dialog to continue if assume the default to the yes/no
choice is is "yes"
Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.
Target Milestone: M15 → M16
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
moving to M18 and nominating for beta3.
Keywords: nsbeta3
Target Milestone: M17 → M18
Keywords: correctness
Keywords: correctnesspolish
Today, while composing a rather important email message in the plain text 
email composer, I accidentally pressed ctrl-Enter, and discovered to my 
horror that it was the hotkey for "Send Now".   AAAAAAARRRRGGGGGGHH! 

PLEASE, if you implement this hot key for Seamonkey, provide a way to 
disable it!
I hit this about once a month or so in 4.x. I think it depends a lot on the 
users typing style. I have hit it a few times when trying to figure out how 
get unstuck from editing a bulleted list.

Having a dialog come up may also be a problem. Generally, those damn dialogs 
only come up when prompting for auto-save, and I usually hit okay straight away.
Maybe the first time the users does that, we could pop up the dialog asking if 
that's the behaviour he wants... then the dialog wouldn't come up any more. 

Can't we have at least have a pref?
I agree that Ctrl-Enter is far too easy to hit accidentally.  Comparing the
slight benefit of having an easy accelerator, versus the continual disaster of
inadvertant sends, I think we should make it more difficult, by dropping the
feature, adding another modifier or perhaps disabling it by default, but adding
a confirmation dialog would be an abomination.  I feel dirty even talking about it.
I'm astounded that so many people seem to have trouble with hitting Ctrl+Enter by 
mistake ... How did you ever survive using 3.x and 4.x?

And is anyone actually going to suggest an alternative shortcut???
I have figured out what it is - ... it's when I'm using ctrl-V to paste 
something, followed by an enter. But if my timing is slightly off, the ctrl
key is still pressed with my left pinky. I think it comes down to 
lack of left-hand/right-hand coordination.

I've tried to keep track of the accelerators that I know are being used. If you 
know of any missing, drop me a note.

Here is the URL for internal folks.  I will attach the file to this bug for 
external folks.

Ctrl+Shift+S is already taken, but Ctrl+Shift+M is available ("Mail")?

Or, we could use Ctrl+Shift+Enter for Send Now. If you're currently offline, it 
would send later.
Attached file SeaMonkey accelerators
Jennifer--can you publish that spec on (or ask someone else to do it 
for you)?  It's easier for some of us to view this stuff when it's not behind the 
firewall.  Thanks!
Users expect that Ctrl+Shift+{somekey} performs an action which is a logical 
counterpart to the one performed by Ctrl+{somekey} -- e.g.:
* Ctrl+S (save) vs. Ctrl+Shift+S (save as), in many apps
* Ctrl+P (print) vs. Ctrl+Shift+P (print preview, or print setup), in many apps
* open page in Navigator (Ctrl+O) or in Composer (Ctrl+Shift+O), in 4.x
* find in this message (Ctrl+F) or in lots of messages (Ctrl+Shift+F), in 4.x.

Therefore, Ctrl+Shift+M to send is inappropriate because it is too close to
Ctrl+M (new message). (The Aphrodite spec has Ctrl+Shift+M opening a dialog 
asking which template you want to use for a new message.)

And Ctrl+Shift+Enter is inappropriate because it would be the complete *opposite* 
of what 4.x (and 3.x) uses by default (Ctrl+Enter for `Send Now' and
Ctrl+Shift+Enter for `Send Later').
We could do something like the standard AIM and have it be a preference. In the 
AOL chat client "Return" means send by default but it can be switched to put a 
return in the message instead; ditto tabs.

I *like* Ctrl-Return and Ctrl-Shift-Return, never have a problem with early 
sends. Sounds like lots of people like it, and certainly lots of people are 
used to it from Communicator. So make it a pref that can be turned off.
I like it, too.  In fact, Microsoft must have realized that it has some value, 
too, because even though it's not published in either UI, the combination can be 
used to send in both Outlook and Outlook Express.
Keywords: mail2
+ per mail triage
Whiteboard: [PDT-] → [nsbeta3+][PDT-]
change summary to reflect wishes of many users who have been burned by this key-
Summary: Ctrl-Enter should send the message → Ctrl-Enter should send the message only if there is pref to turn it off
A better summary might be: "Need key binding for send message", and then try to
pick one that users don't hit accidentally.  I would think that even a lot of
the users who get burned by control-enter might like a key binding for Send, if
it were something that they didn't hit accidentally ... no?  I certainly use
alt-enter a lot.  But I don't want to get into a summary war here.
Here is what I am proposing to do:

Add a pref to turn on/off Ctlr-Enter to send message, the pref will be off by 
default. Like that you wont have a surprise...
Please consider the nagable format.
user w/o pref presses <ctrl>-<enter> a dialog appears explaining what the 
binding does asking should it be bound <enter> would cause yes and send the 
message.  There is work on a prefs panel for boolean toggles, and this would 
easily fit that.
This is turning surreal.

> Add a pref to turn on/off Ctlr-Enter to send message, the pref will be off by
> default. Like that you wont have a surprise...

Yes you will, because if you've used *any* previous version of Netscape 
Mail/Messenger, the keyboard shortcut you've used hundreds of times (or more 
likely, tens of thousands of times) suddenly won't work any more. If that's not 
a surprise, what is?

there is going to be a pref (something which reviewers will laugh at, no doubt) 
to switch the keybinding from Ctrl+Enter/Shift+Ctrl+Enter (for Send Now/Send 
Later) to {something}/Shift+{something}, WHAT is that {something} going to be?
so as not to be understood, my suggestion was that the pref should completely 
disable a keybinding for send now (not toggle between two or more keybindings).

As for compatibility with 4.x, yes, some users might like that but reality is 
that many keybindings will change.  (This is true with every commercial product 
upgrade I've ever made.)
OK.  This discussion needs closure.

Jean-Francois has agreed to implement a pref to control whether the keybinding
ctrl-enter should be active or not.  The default setting of this pref for the
Netscape commercial product will be compatible with 4.x.

No other action is plussed by this bug.  Please file individual enhancement
requests if you care about the other suggestions in this bug.
Priority: P3 → P2
Depends on: 50252
Depends on: 50255
Whiteboard: [nsbeta3+][PDT-] → [nsbeta3+][PDT-] blocked by bug 50252&50255
second pass: - per mail triage

Bug 50252 which we need to fix this on Linux has been marked nsbeta3-.  
Whiteboard: [nsbeta3+][PDT-] blocked by bug 50252&50255 → [nsbeta3-][cut 8/29][PDT-] blocked by bug 50252&50255
So it works on Mac, and can work on Windows once the prepared fix to bug 50255 is 
checked in. Are PDT saying, therefore, that Ctrl+/Cmd+Enter shouldn't be 
implemented on *any* platform, just because it wouldn't work for a while on 
Linux? (Couldn't you do an #ifndef???)
No need for an ifndef -- if it doesn't work, then it doesn't.

How ironic that Linux, the only platform where people didn't mind the old
binding, is the one where it doesn't work!

I still think it's ridiculous that no one is willing to consider an alternate
binding for this very useful functionality.
Maybe we should reconsider our desicion. I can checkin the fix for windows as it 
has been reviewed and tested and quickly implement this key binding. It will 
works on Mac and Window.
oops, I totally forget a little problem. If I implement the keybinding, we will 
have a major problem on linux as CTLR+M (New Message) will be equal as 
CTRL+Enter (Send message). I don't know which one will win but it will be too 
dangerous to do it. Sorry, we must fix bug 50252 first.
Reviewing the key bindings, ^T is the only alphanumeric key I can find which
isn't currently bound in the mail compose window.  Not especially intuitive, but
no less so than ^<Return>.  There are lots of non-alphanumeric keys available,
like ^> (that sorta has a feel of sending to someone -- think redirect -- and
would seem like a fine keybinding for Send Now), ^., ^\, and all the shifted
stuff (though using shifted nonalpha keybindings, like $ or * or whatever, is
likely to run into platform incompatibilities in our event system).

Alternately, argue for the nsbeta3+-ness of 50252 or 46992 (probably the same
bug) so Pav or I can work on them.
Aside from the Linux issues, I don't see where there are any really valid
arguments. A lot of current email programs acknowledge CTRL-ENTER as a SEND
shortcut. Including NS4.x and Microsoft's Email offerings. And if the PDT team
is looking to really compete with a competitor, then obviously NS6 needs to do
everything the competitors do, better. I think this one is a no brainer.

Plus, chicks dig it.
*** Bug 56696 has been marked as a duplicate of this bug. ***
IMO, we shouldn't have a pref, but a key which is unlikely to be hit during

I think, Ctrl-Enter is much more likely to be hit accidently than Alt-Enter.
This user might accidently have his left hand rest on Ctrl, or he might be
trying to hit Shift-Enter, but get the wrong modifier. For the same reason,
Crtl-Shift-Enter is not a good key IMO, because the user might try to hit
Shift-Enter and accidently also press Ctrl.
I don't see such a risk for Alt (neither in theory, nor in my experience.
Unfortunately, we don't seem to be allowed to use Alt for shortcuts.

I propose Ctrl-0. It can be access quickly (one key per hand), and doesn't seem
to be taken.
Or what about the function keys? I don't see any of F1..F12 being taken. Any of
them (other than F1 and F10) would be fine with me, or Ctrl + any of F5..F12.
Depends on: 56696
*** Bug 57052 has been marked as a duplicate of this bug. ***
sorry for the extra email. Removing mail2 keyword.
Keywords: mail2
Adding mail3 keyword.
Keywords: mail3
*** Bug 47708 has been marked as a duplicate of this bug. ***
I think the shortcut for Send should Alt+S, just as in Outlook and ICQ. It's
very fast, and in the Mail Compose window, Alt+S isn't currently used for
anything that I can see.

In all cases I think we should be consistent using Alt+ the first letter of the
function (at least Alt+ in Windows, which is used a great deal for hotkeys),
unles the Alt+ is taken and then we could find a reasonable alternative, like
Alt+Shift+ or something else. Something that can be done with one hand and only
two fingers when possible. Alt+ is just a roll of the thumb and a tap with the
index finger. I love it.

See bug 55679 where I discuss that the toolbars in Mozilla that currently have
hotkeys, just as their counterparts on the menu toolbar do, just like Outlook
does, and so on. 
Ctrl-Enter should still be supported, in addition to any other hotkey for a 
number of reasons:
1. NS4.x parity
2. Parity with Outlook and Outlook express (the currently most common mail 
3. Chicks dig it.

But 1 and 2 are the most important.
ctrl-s is save, this has already been argued. We need to support ctrl-enter, if 
you want to argue ctrl-s, please file a separate bug. [Actually don't as I 
suspect we already have one marked won't fix, but ...]
I second the Alt+S.  I see two problems with Ctrl+Enter.
 1. The aforementioned accidental hitting (never had that problem... in fact,
    until I read it hear, I didn't realize Outlook even had that option.
 2. In all other Win32 apps with drop down AutoComplete, you can use the arrow
    keys to select the option you want, and then hit Ctrl+Enter to select it.
    This currently doesn't work in Mozilla (I was looking to see if there was
    already a bug on this when I found this bug).
Kovu, jake, read above. Alt is reserved.
> move away from Alt as shortcut and leave this for menmonics only

I assume that's what's being refered to above... That's fine.  Make the Send
button have a menmonic of "S" (as Outlook does).
marking nsbeta1=, moving to mozilla0.8.  This is for putting back Ctrl-Enter.  A
hidden pref to turn it off is fine.
Keywords: nsbeta3
Whiteboard: [nsbeta3-][cut 8/29][PDT-] blocked by bug 50252&50255 → [nsbeta1+]blocked by bug 50252&50255
Target Milestone: M18 → mozilla0.8
change qa contact
QA Contact: esther → sheelar
Reassigning QA Contact to nbaca.
QA Contact: sheelar → nbaca
Tens of millions of AIM, Netscape 3.x/4.x, ICQ, AOL, and Outlook users have 
this shortcut ingrained in their brains.  We really shouldn't change it.
*** Bug 64661 has been marked as a duplicate of this bug. ***
Just as an additional note - I've been suffering from "accidental mail send" in 
NS 4.x for several years, and couldn't ever work out which key combo it was that 
I was accidentally hitting! Now I've read this bug, I know...

Believe me, Ctrl-Enter problems are probably more widespread than you think - 
people just blame it on "the software playing up" - I know I did for a while.

By the way, why aren't we having total UI key rebindability, like in e.g. Word 
or a decent editor? Surely XUL makes this reasonably easy; then we wouldn't have 
to have a special hidden pref for every key someone didn't like...

Right now, it looks like most people want this:

1. User installs Mozilla.
2. user writes an email message, and presses ctrl+enter.
3. Dialog pops up:

|Do you wish to send the message now?|
|                                    |
| [ ] don't ask me this again        |
|                                    |
| [OK]           [Cancel]            |

4. if user checks "Don't ask me this again" and clicks OK, from now on
ctrl+enter won't pop up the dialog but will immediately send the message.

5. if user checks "Don't ask me this again" and clicks Cancel, from now on
ctrl+enter won't do anything.

6. In addition, there will be a pref for this.

For bonus points, the pref could be a drop-down list for which key binding you
want for send:
- None
- Ctrl+enter
- Alt+enter
- Alt+S
- F6 or whatever

Is my summary accurate? Please comment if not.
f6 is *very* unavailable.
I like the basic dialog, but shouldn't the buttons be:

  Windows: Yes      No
  Mac:     Send     Don't Send
  Linux:   ???      ???

Timeless: What's F6 used for (just curious) ?
Re the last few entries: You probably want to look at bug 18508 (fix regression
to let user specify keybindings) and bug 57805 (UI for custom key bindings).
The dialog sems fine (make the buttons on linux the same as the mac ones) as
long as it has "remember this", as it does in the example.
Re mapping the keybinding to something else: we have no way of saving the result
unless 18508 is fixed.
ie5.5's definition:
<tr><td>Move forward between frames.</td>
<td>CTRL+TAB or<BR>F6</td></tr>

nc4.x's definition is at least slightly confused. you should encounter the bug 
where i described it. references include: bug 30864, bug 48251, bug 35134

Please read /your/ bug 30864 esp my Comments 2000-08-01 22:31 and 2000-08-11 20:08.

to borrow law's phrase: Oh dear. I'm removing [f6 from consideration] for 
obvious reasons (I hope).
I strongly support Moses Lei's idea from 2001-01-10 14:17.

It seems the only method which will make everyone happy:
 - CTRL + Enter, a widely used shortcut is supported.
 - There is only ever one dialog box for people who want this function
 - People who don't want this function can easily disable it, and should never
accidentally send a message.

You shouldn't need to go into the preferences to setup your keyboard bindings.
How would this interact with the autospell pref? As there is currently no way to
detect an aborted spell, a prompt here would be very useful.
in nc4 if you have spell check on send set then it will spell check on 
ctrl+enter, and if you abort the spell check the send will abort.

That is NOT part of this bug, spell check issues are covered in other bugs, and 
since we have no spell check engine [another bug] it is certainly not relevant 
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
marking nsbeta1- and moving to future milestone.
Keywords: nsbeta1nsbeta1-
Whiteboard: [nsbeta1+]blocked by bug 50252&50255 → [nsbeta1+ 2/21]blocked by bug 50252&50255
Target Milestone: mozilla0.9 → Future
This bug is mostfreq. Nominating for mozilla1.0.

Keywords: mozilla1.0
OK, this bug cracks me up.  It's the perfect example for people who argue 
against open source:

1. Start with a simple task.
2. Allow everyone to comment.
3. Keep going in circles for well over a year.
4. Keep pushing it off to later and later dates.

Sorry, it's just that everytime I see this getting pushed off yet again, I laugh 
a little more.
Even if we would not have pushed this bug again, we would not have been able to
go forward with it until bug 50255 is fixed. Once bug 50255 is fixed, we will
look again closely at this one. Until then, we have way much more other
important stuff to fix.
Bringing back nsbeta1+ to have some accelerator that can send a message.
Keywords: nsbeta1-nsbeta1
Whiteboard: [nsbeta1+ 2/21]blocked by bug 50252&50255 → [nsbeta1+]blocked by bug 50252&50255
Target Milestone: Future → mozilla0.9
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Re-assigning to varada
Assignee: ducarroz → varada
Marking dependant on 76891 - Ctrl-Enter event is not being recognized on Windows.
Depends on: 76891
moving to 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 79142 has been marked as a duplicate of this bug. ***
*** Bug 83022 has been marked as a duplicate of this bug. ***
What's going on with this bug?  Even in win32 is broken we should get the
functional part of the patch in for mail/news.  It might motivate people to get
win32 fixed.
Does this code work other than the CTRL+Enter being broken (i.e. if it was
changed to a different key combination then would it work)?

If so, then I see no reason not to check this in when the tree branches.
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Can this keyboard shortcut be implemented, or is no one willing to do it?  It
seems to me that Moses Lei proposed the right idea (2001-01-10 14:17), but it
keeps getting pushed further and further out.

I think at this point, it should either be implemented, or scrapped entirely.
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
So if this is in 9.4, how can the bug this depends on (50255) be in 9.5?
Rod spears moved it up on the 21st to 0.9.5 from 0.9.4.
Fine, but let's move the bugs this depends on up as well.
this isn't going to hold up the .9.4 branch so moving to .9.5. We'll work with
Rod to fix  50255 and then consider the fixes for the eMojo branch.
Keywords: nsbranch+
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Looks like there's another dup of this bug over in: 56696 which also has a patch.
How does this ancient bug that shipped with 6.1 suddenly become *critical* for
the current release?
I'm actually amazed that we didn't plus or move up the last bug that this
depends on: bug 50255, and it looks like 56696, where the patch resides, needs a
review. Here's the deal: We continue to not have a keyboard accelerator for
sending a mail message. I may turn this into a personal vendetta on open source
if we don't get this fixed soon. :-) The fact is, this *is* critical for any
release we might do, be it Netscape commercial or a mozilla milestone. This has
swirled for *years,* and I think we're close if roc+moz's patch in 56696 flies.
Updating summary to remove resolved dependency (50252).
If someone thinks this should be a dupe of 56696, please mark it so.
Whiteboard: [nsbeta1+]blocked by bug 50252&50255 → [nsbeta1+]blocked by bug 50255
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: [nsbeta1+]blocked by bug 50255 → [nsbeta1+]blocked by bug 50255,[corretctness]
Whiteboard: [nsbeta1+]blocked by bug 50255,[corretctness] → [nsbeta1+]blocked by bug 50255,[correctness]

*** This bug has been marked as a duplicate of 50255 ***
Closed: 23 years ago
Resolution: --- → DUPLICATE
sorry about that. ignore that. I was trying to bring up bug 50255 and typed in
the wrong field =).
Resolution: DUPLICATE → ---
Nobody has touched 50255 in a month, and it does not have nsbranch+. This looks
like a polish bug, that it is too late to resolve. PDT-

Pls feel free to bring this to the PDT if you have a fix, and strongly belive
this is a stop ship bugger.
Whiteboard: [nsbeta1+]blocked by bug 50255,[correctness] → [nsbeta1+]blocked by bug 50255,[correctness],PDT-
Do we have any key-combination that sends the mail, or is this mouse-only? If
there's a keyboard send function, I think that it's not as big a deal as it
would be with no way to send from the keyboard.
now that I'm actually USING Netscape 6.x, I find this bug really annoying.

I don't need to use the mouse to type a message, why do I need it to SEND a
message.  I really liked that funcationality in Netscape 4.x (or every other
mail client, for that matter).

Please, someone, add the accelerator.  It's been almost 2 years waiting for this
minor-but-frustrating bug to get resolved.
I agree.  It is the little interface issues that are holding people back from 
using Mozilla.  Every power-email-user I know EXPECTS to be able to send email 
by that key combo.

I couldn't care less if there is a pref to turn it off though.  Save that for later.
There is a non-mouse way to send: Alt-F, d   It's a three-key, two-stroke combo
and I hate it (especially when menus are being slow) but it's better than using
the mouse.
I think there is general agreement that this is badly needed. This relies on bug
50255 and the engineer that owns that bug is pretty doomed with other work. If
we truly want this bug, someone needs to help get 50255 fixed, which as I
understand it, is high-risk and fairly complex. Anyone wanna help rods fix 50255?
If someone can tell me where 50255 is at, and even better provide a test case
for all keys that are currently broken, I can take a run at it.  No promises,
I'm minusing this bug at this time because we need a fix for 50255 and it looks
unlikely that that fix is going to happen in time for eMojo. 
Keywords: nsbranch+nsbranch-
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Reminder:  this bug has evolved into "when ctrl-enter sends a message, please 
make a preference to disable the keybinding for those of us who are prone to 
accidentally pressing accelerator-enter when typing text"

Strictly speaking, it's not dependent on #50255 (but #56696 is).
No longer depends on: 50255
This bug was fixed with my checkin for bug 56696 (my patch brings up a warning
dialog box when you press Ctrl-Enter; there is a checkbox in the dialog which
activates a pref to disable the dialog permanently).

However, bug 50255 means the feature still doesn't work on Windows. If you're
using Windows, please direct your votes and attention there.

Maybe we should leave this bug open until 50255 is fixed, so people can find
this before they submit a duplicate bug.
I thought the dialog that came up had a checkbox that was for never opening the 
dialog again.

This bug is for allowing users to essentially disable the keybinding (have it 
never send a message).  Do we need another checkbox or a set of 3 radio buttons:
  o Always prompt me
  o Don't prompt me, send anyways
  o Don't prompt me, don't send
(wording to be revised of course)
from seth in bug 56696, 2001-10-01 12:01 comments:

jglick, the current dialog has a checkbox to allow the user to disable the 
confirmation dialog.

[ ] Do not show me this dialog box again

is currently hooked up to the "mail.warn_on_send_accel_key" pref.

I think that showing the alert is a good idea to prevent the user from sending 
before they meant to.

"Send the message now?", what about if we are offline?  
In that case, ctrl+enter is really going to be doing a "send later".
I think that if you're offline that you have to use ctrl-shift-enter to activate
Send Later.  It doesn't seem to be smart enough to automatically change the binding.
Oh, and I think that there should be something in the pre UI to set this setting
by hand.  Right now to get the dialog back you have to edit the config file
as far as I understand this bug, we'd need another pref to disable ctrl+enter 
from sending the message.

the existing pref (that roc added) is only for controlling if we show the 
warning dialog or not.
the UI issues for the new warning dialog are covered in bug

there is a UI issue, if we add a pref to allow the user to disable ctrl+enter 
all together.  see #102643 for that issue.
Blocks: 104166
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Blocks: 107067
Keywords: nsbranch-
QA Contact: nbaca → olgam
Keywords: mail3nsbeta1+
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 113116 has been marked as a duplicate of this bug. ***
Replacing duplicate with the real bug number.
Depends on: 50255
No longer depends on: 76891
No longer blocks: 107067
I'm going to move this out.

Right now Ctrl+Enter works. There is a confirmation dialog.  There is a pref to
turn that confirmation dialog on or off by going into the main mail pref panel.
 Those who want  Ctrl+Enter to work all the time can turn the confirmation
dialog off. Those who are worried that they might press Ctrl+Enter accidentally
can turn the confirmation dialog on.  The only case we haven't solved is the
case where someone might hit Ctrl+Enter followed by an Enter accidentally and
unintentionally send the message.  I think that case isn't too likely and
doesn't warrant adding an additional pref in the near future if ever.
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla0.9.9 → Future
*** Bug 133859 has been marked as a duplicate of this bug. ***
Based on the reasons given in comment #129 this bug is about a trivial as can
be. Suggest to change Priority to "P5" and Severity to "Enhancement".
Suggest marking worksforme.  If the string of events in comment 129 actually
turns out to be a big problem, it can be addressed in a new bug.
I remove nsbeta1- keyword - it was for MachV.
Keywords: nsbeta1-
Now I add 'nsbeta1' keyword for Buffy. Sorry, it's faster to edit multiple bugs
at once than manually go to each and remove minus.
Keywords: nsbeta1
The way to address comment #129 is to make "Don't send" the default button in
the confirmation dialog, thus making the sequence C-enter enter do nothing.

Let's close this bug!
Keywords: nsbeta1nsbeta1-
QA Contact: olgam → laurel
taking all of varada's bugs.
Assignee: varada → sspitzer
Ctrl-Enter is not sending in build 2003032611. I have no idea when this might
have regressed, but 1.3 final worked fine.

removing nsbeta1- for re-consideration, this was a big deal for many of the 4.x
holdouts and they will not like it going away again.
Keywords: nsbeta1-nsbeta1
Crl-Enter not working is bug 198976.
Keywords: nsbeta1nsbeta1-
I can tell you that it did work on 20030303 but it isn't working in Mozilla/5.0
(X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326 and 1.3 is 20030312, so it's
sometime between those dates.
hi all..

have Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 and
ctrl+enter doesn't work in the message body.. it work in the subject line and in
the adress (to, cc,..) line... but not in the message body...

Hi everyone,

I'm a newbie to bugzilla, and found this bug while trying to figure out why my 
ctrl-enter stopped working after i upgraded to Mozilla/5.0 (Windows; U; Win 9x 
4.90; en-US; rv:1.4a) Gecko/20030401.  I'm very impressed with how many years 
of effort you guys have put in to a simple shortcut key!

Anyhow, the prob is exactly as described in comment #141, I'm guessing the ctrl-
enter is somehow trapped by the compose front-end when the cursor is in the 
main text panel, as it results in a carriage return on the page.  This might 
mean a bug needs to be submitted to the people who work on that bit.  (I don't 
know exactly where though - so if someone else a bit more experienced wants 
to... feel free!).

Also it should be displayed in the file menu as 'ctrl-enter' in win9x, 
not 'ctrl-return'.
ctrl-enter not working is bug #198976, and appears to now be fixed
incorrect menu text is bug #106327 
apologies for spam while i learn how to use bugzilla :(
This has been fixed for ages.
Closed: 23 years ago21 years ago
Resolution: --- → FIXED
reopening bug
If indeed this bug is fixed, the pref for NOT sending a message should be listed
in the bug somewhere.  A quick scan of all recent comments does not list the pref.
Resolution: FIXED → ---
brade, the dialog which comes up when you press Ctrl-Enter has a checkbox "Do
not show me this dialog box again".
brade, the dialog which comes up when you press Ctrl-Enter has a checkbox "Do
not show me this dialog box again". There is also a checkbox in the Prefs
dialog: "Mailnews|Composition|Confirm when using keybord shortcut to send message".
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Please open a new bug for any regression bug.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.