245989 - Ctrl+Enter Send shortcut moves caret cursor to next recipient input - was: Ctrl-Return in filled address line doesn't send mail by keyboard Return (mouse click OK works) during autocomplete

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Markus Merz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608

It does not work in all the last versions including the latest 1.8a2 from monday
June 6th.

If I create a mail, sent as new or use a template and I want to send the mail by
Ctrl-Return and then answer the following dialogue by return does not work when
I do the Ctrl-Return while inside a filled To: address line.

If you are in the next line which is empty it works.

Reproducible: Always
Steps to Reproduce:
1. create a mail, sent as new or use a template
2. (optional) edit subject and/or body
3. fill in address
4. Hit Ctrl-Return while in the filled address field
5. dialogue box pops up: Are you sure you are ready to send this message?
6. Hit Return to answer the default button "Send"
7. *Bug* Point 6. is not accepted, nothing happens
8. ESC for "Cancel" works.
9. Mouse click on "Send" works
Actual Results:  
nothing happens

Expected Results:  
Mail should be sent.

Comment 1

[Markus Merz]

Again confirmed comment 0 in 1.7rc3
For QA 1.7-final I flagged it "1.7?"
If it is to minor for 1.7 it should be fixed in 1.8.

Comment 2

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040608] (<-- 1.7rc3 !)
(W98SE)

It's a (stealing) focus issue:

(In reply to comment #0)

> 6. Hit Return to answer the default button "Send"
> 7. *Bug* Point 6. is not accepted, nothing happens

Details:
6a. Dialog opens, with focus on "Send", which is fine so far.
6b. _Then_, Ctrl-Enter processing sets the focus to the next (empty) line in the
list: the dialog is still activated, but it has lost actual focus :-(

> 8. ESC for "Cancel" works.
> 9. Mouse click on "Send" works

These work, because they either set or don't care about focus...

Comment 3

[Markus Merz]

(In reply to comment #2)
> list: the dialog is still activated, but it has lost actual focus :-(

You are right. Good diagnosis! I can confirm. If you do:
[...]
5. dialogue box pops up: Are you sure you are ready to send this message?
6. Hit Return to answer the default button "Send"
7. *Bug* Point 6. is not accepted, nothing happens

workaround:
- hit Cancel in 7.
- (expected result) to be back in the original address line
- (focus stolen result) Cursor is in the next empty line
- Hit Ctrl-Return again
- hit return
- mail is sent

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)
> workaround:
> - hit Cancel in 7.

Or simply hit Tab (twice, I think) to get the focus back to the 'Send' button...

Comment 5

[Asa Dotzler [:asa]]

not a recent regression as far as I can tell and it has a simple workaround for
keyboard users to just don't show the dialog again.

Comment 6

[Wayne Mery (:wsmwk)]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a

Comment 7

[Markus Merz]

Just checked it with Thunderbird (!)
Still same behavior in TB Version 1.5 (20051201)
So I reopen the bug for product Thunderbird.

Comment 8

[Markus Merz]

Sorry, checked it again with TB.
It works fine!
Pressing the right key combination helps :-)
Instead of Ctrl-Return I checked it with Ctrl-R.

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> WFM

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060311 SeaMonkey/1.5a] (nightly) (W98SE)

I confirm that the main issue is fixed:
The dialog now retains its focus.

But the underlying issue is still there:
There is no reason why step 6b should move the cursor to the next address line or to subject field or to message body.
In case one cancels the dialog, he has to move the cursor back then.

Reopening:
We seem to miss Ctrl+Return to disable simple-Return (cursor) processing.

Comment 10

[Wayne Mery (:wsmwk)]

in v2 and trunk, during autocomplete ctrl ...
 ctrl+a moves caret to start of string (interesting emacs-like behavior)
 ctrl+z temporarily undoes autocomplete
 ctrl+del deletes words
 ...

but no send dialog via ctrl+return.

similarity to FF bug 237504, but it no clue what fixed it in FF.
do they use the same autocomplete tool?

Comment 11

[u294409]

Close as WORKSFORME (TB Trunk).

Comment 12

[Wayne Mery (:wsmwk)]

=>WFM

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)
> Close as WORKSFORME (TB Trunk).

(In reply to comment #12)
> =>WFM

Could you add details about which build you tested ? And how ?


[Mozilla Thunderbird, version 3.0a1pre (2008020313)] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008020302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Bug still there, as described in comment 9:
"File > Send Now", "File > Send Later" and "Send" (toolbar) button do not move the cursor to a new blank address line :-)
But Ctrl+Return and Ctrl+Sfhit+Return do :-(

Reopening;
and moving to Core product.

Comment 14

[Wayne Mery (:wsmwk)]

my bad. I should have remembered there was I reason I didn't close it before

Is this just windows, or is it OS=ALL?

Comment 15

[Thomas D. (:thomas8)]

Reported against the pre-pills addressing area (one row/input per recipient), which went away with TB 78.
We've had some issues in TB 78 regarding the functionality of these shortcuts especially on MAC, but Alex and I have thoroughly fixed this.

There's toolkit autocomplete issue that Cmd+Enter is blocked on Mac because "it beeps".
https://searchfox.org/mozilla-central/rev/c7cf087b6e1384608ca3989f042f12f7cabd0a5f/toolkit/content/widgets/autocomplete-input.js#556-561
Alex worked around half of that in bug 1682147, and I fixed the rest in bug 1696790.

(In reply to Serge Gautherie (:sgautherie) from comment #9)

We seem to miss Ctrl+Return to disable simple-Return (cursor) processing.

Changing bug to a minor subissue without changing summary or opening a new bug isn't ideal in terms of bug management...

Fwiw, we definitely do no longer respond to any shortcut key with modifiers + Enter for moving the caret to the next address row:
https://searchfox.org/comm-central/rev/991a6842fdbe755a625e08e399442de3970ce243/mail/components/compose/content/addressingWidgetOverlay.js#739-766
Only plain Enter on an empty input will move the caret to the next address row.

Comment 16

[Thomas D. (:thomas8)]

    case "Enter":
      // Break if unrelated modifier keys are used. The toolkit hack for Mac
      // will consume metaKey, and we'll exclude shiftKey after that.
      if (event.ctrlKey || event.altKey) {
        break;
      }

      // MacOS-only variation necessary to send messages via Cmd+[Shift]+Enter
      // since autocomplete input fields prevent that by default (bug 1682147).
      if (event.metaKey) {
        // Cmd+[Shift]+Enter: Send message [later].
        let sendCmd = event.shiftKey ? "cmd_sendLater" : "cmd_sendWithCheck";
        goDoCommand(sendCmd);
        break;
      }

      // Break if there's text in the address input, or if Shift modifier is
      // used, to prevent hijacking shortcuts like Ctrl+Shift+Enter.
      if (input.value.trim() || event.shiftKey) {
        break;
      }

      // Enter on empty input: Focus the next available address row or subject.
      // Prevent Enter from firing again on the element we move the focus to.
      event.preventDefault();
      SetFocusOnNextAvailableElement(input);
      break;

(and a similar function for custom headers)