Closed Bug 966155 Opened 6 years ago Closed 6 years ago

Regression: Cmd + left defect in Thunderbird since 2014-01-24


(Core :: DOM: Editor, defect)

Not set



Tracking Status
firefox28 --- unaffected
firefox29 + fixed
firefox30 + fixed


(Reporter: soeren.hentzschel, Assigned: ehsan)



(Keywords: regression)


(1 file)

I regularly use Cmd + left to jump to the beginning of the line in the message compose window of Thunderbird on OS X 10.9. But It's defect since 2014-01-24 Daily.


1. Reply to a mail
2. Type something
3. Press Cmd + left

Expected result:

cursor goes to beginning of the line

Actual result:

cursor remains on this position.

New mails are not affected, only replies. And if you click in a quoted part and then move the cursor back to your message, it works again.

Related to Bug #289384?

The fix landed on 2014-01-23, on 2014-01-23 there was no Thunderbird build, the build from 2014-01-24 was the first build with this bug.
Blocks: 289384
This is probably a dupe of bug 966552.  I landed a fix for that to inbound a few hours ago.  If you can still reproduce with that patch, please reopen the bug.
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 966552

I have no permissions to reopen the bug, but it's not fixed in Thunderbird. Additionally cursor up/down/left/right no longer works before clicking in the editor.
Flags: needinfo?(ehsan)
Sören, can you please paste the mozilla-central changeset ID that your Thunderbird build is based on?  There is a link to that page from Help -> Troubleshooting Information.
Flags: needinfo?(ehsan)
Flags: needinfo?(cadeyrn)
Built from
Flags: needinfo?(cadeyrn)
Hmm, so Cmd+Left used to work for you *before* bug 289384 but stopped working *after* it?  That is very surprising, since that is exactly what that bug fixed...  Is that when composing a plaintext email or an HTML email?

Neil, do you know what special thing Thunderbird does with its key bindings?
Ever confirmed: true
Flags: needinfo?(neil)
Resolution: DUPLICATE → ---
I think it stopped after landing of bug 289384, I know that in works in 2014-01-22 Daily and stopped working with the 2014-01-24 Daily. And after landig of bug 966552 the cursor keys (without cmd) also stopped woking, now I have to click in the editor.

It affects both, html and plaintext mails.
Thunderbird doesn't do anything special, as far as it's concerned, compose is just a design mode document.

Interestingly those workarounds of clicking in various places suggest that focus is out of sync.
Flags: needinfo?(neil)
OK I did a trunk build of Thunderbird and I cannot reproduce either of these problems.

Can you please try again in safe mode?
Flags: needinfo?(cadeyrn)
same problem in safe mode. I have to click in the editor to get the keys working. But without clicking the commands are broken.
Flags: needinfo?(cadeyrn)
OK, so we need to figure out how to reproduce this so that I can debug it.  Please create a new profile, and go through all of the steps you take to hit this bug and document everything here so that I can follow your footsteps and reproduce this here.  Thanks a lot!
Flags: needinfo?(cadeyrn)
Here's my STR on Linux:

1. Load the following page:
data:text/html,<input><iframe onload="contentDocument.designMode = 'on';">
2. Type some text into the design mode document
3. Click on the text field
4. Tab back into the document
5. Notice that Ctrl+Bksp no longer works
(obviously I had to pick a different keybinding here)
OK, this I can reproduce, and I think I know what's going wrong.
Assignee: nobody → ehsan
Flags: needinfo?(cadeyrn)
Comment on attachment 8376877 [details] [diff] [review]
Ensure that we handle the native key bindings for all key events in designMode documents; r=Neil

This is a sibling of bug 966552 in a sense.
Attachment #8376877 - Flags: review?(neil)
Component: Message Compose Window → Editor
Product: Thunderbird → Core
Comment on attachment 8376877 [details] [diff] [review]
Ensure that we handle the native key bindings for all key events in designMode documents; r=Neil

(I hadn't noticed when doing the previous related reviews but the previous editor tests don't bother opening a new window, instead they just embed the design mode frame in the test document. I'm just thinking of the time it takes these tests to run, so ignore me if there's a compelling use for opening a new window.)
Attachment #8376877 - Flags: review?(neil) → review+
I open new windows for tests that are particularly sensitive to focus related things to make the test resilient to future changes in things in the main browser window which can change our focus assumptions.  FWIW opening new windows is pretty fast, our most slowest mochitests are the ones which basically wait for a long time sitting there doing nothing.
Comment on attachment 8376877 [details] [diff] [review]
Ensure that we handle the native key bindings for all key events in designMode documents; r=Neil

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 289384
User impact if declined: comment 0.  Also this is pretty similar to bug 966552 and can break all sorts of things if left unfixed.
Testing completed (on m-c, etc.): locally
Risk to taking this patch (and alternatives if risky): minimal
String or IDL/UUID changes made by this patch: none
Attachment #8376877 - Flags: approval-mozilla-aurora?
Keywords: regression
Blocks: 966449
FYI, I will wait for this patch to land in m-c before uplifting it.
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Sören, can you please verify that the Thunderbird build including this patch fixes the bug?  Thanks!
Flags: needinfo?(cadeyrn)
Yes, it works. Thank you. :)
Flags: needinfo?(cadeyrn)
No, thank _you_ for reporting the bug and all of your help to guide us how to fix it!  :-)
Attachment #8376877 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.