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

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Sören Hentzschel]

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.

STR:

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.

Comment 1

[(no longer active)]

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.

Comment 2

[Sören Hentzschel]

Hi,

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.

Comment 3

[(no longer active)]

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.

Comment 4

[Sören Hentzschel]

Built from http://hg.mozilla.org/mozilla-central/rev/b80f7eece913

Comment 5

[(no longer active)]

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?

Comment 6

[Sören Hentzschel]

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.

Comment 7

[[e-mail]]

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.

Comment 8

[(no longer active)]

OK I did a trunk build of Thunderbird and I cannot reproduce either of these problems.

Can you please try again in safe mode?

Comment 9

[Sören Hentzschel]

same problem in safe mode. I have to click in the editor to get the keys working. But without clicking the commands are broken.

Comment 10

[(no longer active)]

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!

Comment 11

[[e-mail]]

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)

Comment 12

[(no longer active)]

OK, this I can reproduce, and I think I know what's going wrong.

Comment 13

[(no longer active)]

Attachment: Ensure that we handle the native key bindings for all key events in designMode documents; r=Neil

Comment 14

[(no longer active)]

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.

Comment 15

[[e-mail]]

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.)

Comment 16

[(no longer active)]

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.

https://hg.mozilla.org/integration/mozilla-inbound/rev/58f4e679f019

Comment 17

[(no longer active)]

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

Comment 18

[Sylvestre Ledru [:Sylvestre]]

FYI, I will wait for this patch to land in m-c before uplifting it.

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/58f4e679f019

Comment 20

[(no longer active)]

Sören, can you please verify that the Thunderbird build including this patch fixes the bug?  Thanks!

Comment 21

[Sören Hentzschel]

Yes, it works. Thank you. :)

Comment 22

[(no longer active)]

No, thank _you_ for reporting the bug and all of your help to guide us how to fix it!  :-)

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/05c3913ec2d0