459949 - Broken focus (arrow keys, copy and paste don't work) in non-recycled compose windows

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Joe Sabash [:JoeS1]]

Steps:
 1. Open a mail composition window in whatever mode you want (HTML/Plaintext)
 2. Check the the arrow keys move the cursor in the compose window
 3. Abort the composition don't think it matters (send/send/later or save)
 4. Open a composition in the opposite format (shift/click) or another domain pref
 5. Note the the arrows fail to move the cursor

It seems that with the second attempt to compose in that mode, arrows work.

Another possibly related symptom, when trying to compose HTML (for the first time after plaintext compose) The Format and Insert buttons are grayed out on the toolbar as well as most items on the formatting toolbar.

In all cases calling the composer for the second time for the same mode fixes everything.

A forums tester noted this on a 20081010 build, and I have noticed it for the past 3-4 days.

As for regression date, all I can say is that the problem is not in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3

Comment 1

[Magnus Melin [:mkmelin]]

I don't seem to see this on linux (latest trunk).

Comment 2

[Joe Sabash [:JoeS1]]

Additional testing:
Symptoms the same in safe mode,
Regression range:
First appears in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081010 Lightning/0.6a1 Shredder/3.0b1pre ID:20081010031350

Previous nightly is OK

Comment 3

[Jay Rossiter]

I've been seeing this for a few days - very irritating behavior.

Switching windows and then switching back to the editor causes the navigation to work; you don't have to close the window, just de/reactivate it.

Also applies to Home/End buttons.

Comment 4

[Magnus Melin [:mkmelin]]

C-c checkins:
<http://hg.mozilla.org/comm-central/pushloghtml?startdate=2008-10-09+03%3A00%3A00&enddate=2008-10-10+03%3A13%3A50>

M-c checkins:
<http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-10-09+03%3A00%3A00&enddate=2008-10-10+03%3A13%3A50>

Comment 5

[Jay Rossiter]

My guess is that it would have been caused by the fix for #426766 (http://hg.mozilla.org/mozilla-central/rev/abd911498db3) in the M-c checkins list.

Uri's other change (http://hg.mozilla.org/mozilla-central/rev/335b63a03aba) could also be related.  But, I don't know the code.  Both of those changes modified selection and focus.

Comment 7

[Magnus Melin [:mkmelin]]

Uri: caused by bug 426766?

Comment 8

[Uri Bernstein]

Hmm... I can't see how my patch would have caused this. I suspect it might rather be bug 365467 (http://hg.mozilla.org/mozilla-central/rev/0e52c4677cb4). Neil - care to take a look?

Comment 9

[Uri Bernstein]

Oops, wrong Neil. (how did that happen?)

Comment 10

[Uri Bernstein]

I can't reproduce this on Mac with: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081017 Shredder/3.0b1pre

(Also, it was the right Neil. Sorry for the spam).

Comment 11

[[e-mail]]

I tried two debugging styles here. The first was to add dump() statements to SetMsgBodyFrameFocus. For some reason I the focus controller wasn't noticing the shift in focus from the XUL window to the message body. I then tried stepping through the debugger. Of course this time the focus controller did update...

Comment 13

[[e-mail]]

Well, this is going to be fun to debug, given that merely running the process under a debugger (either VS8 or WinDbg) causes the problem to go away...

Comment 14

[[e-mail]]

OK, so I'm getting a weird focus event. According to the stack, I'm getting the event in response to the load of messengercompose.xul causing the release of a previous document viewer that owns a view manager that owns a view that owns a widget that has focus, causing Windows to move the focus to another window. However this focus event does not have an associated activation event so the focus controller is never unsuppressed and therefore refuses to move focus.

Comment 15

[[e-mail]]

Attachment: Stack trace

Comment 16

[Wayne Mery (:wsmwk)]

bug 459205 a dupe?

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

This makes email composition unusable. 
Is there a workaround?
Is there a way to make the mail composer stop using recycled windows?
Some hidden pref, maybe?

Comment 18

[Wayne Mery (:wsmwk)]

(In reply to comment #17)
> This makes email composition unusable. 
> Is there a workaround?
use build prior to 20081010031350 or ...

> Is there a way to make the mail composer stop using recycled windows?
> Some hidden pref, maybe?

advance options, plug in "recycled", "0" should disable
ref: http://kb.mozillazine.org/Mail_and_news_settings


really needs to get into b1. if not fixed real soon perhaps backing out bug 365467 is the short term answer - that bug was open for a year.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Hmm.  Maybe I had it backwards.  It seems worse now with zero.
Perhaps I should have asked, is there any way to force it to use 
recycled windows?  Of course, that sounds silly, even to me. :)

Comment 20

[Joe Sabash [:JoeS1]]

(In reply to comment #19)
> Hmm.  Maybe I had it backwards.  It seems worse now with zero.
> Perhaps I should have asked, is there any way to force it to use 
> recycled windows?  Of course, that sounds silly, even to me. :)

My workaround is minimize/maximize the composition window.
Evidently, that makes it a recycled window.

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

Joe's workaround solves some problems, but it doesn't make paste-as-quotation
work (ctrl-shift-v on windows).  Maybe that's a separate bug with a separate
cause (?) in which case, at least one of the bugs marked as duplicates of 
this one are not actually duplicates.

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

Ah HA!  The paste-as-quotation bug is the loss of a keyboard shortcut.  
The Edit menu option still works.  The keyboard shortcut does not.
The keyboard shortcut is no longer shown in the Edit menu.
I'll file a separate bug.

Comment 23

[Wayne Mery (:wsmwk)]

simpler workaround than minimize+maximize for me is simply focus another window and come back. neither recyle setting nor the old standard of save draft work for me. very ugly

msg body is the only place that has trouble. subject and addresses are OK.

Comment 24

[[e-mail]]

Attachment: Rip out the broken code

Pinging ere since I think the code I'm removing was conflicting with some code although I forget which and he might be able to verify this.

Pinging bienvenu in the hope that he can actually test whether MAPI opens windows correctly (or at least no worse) with the patch applied.

Comment 25

[David :Bienvenu]

Comment on attachment 344394 [details] [diff] [review]
Rip out the broken code

no worse - with or w/o the patch, I'm not seeing the compose window come forward (the taskbar flashes, so it's annoying but not too confusing for the users who know what a flashing task bar means). Given that this fixes a bigger usability issue, I'd say go for it.

Comment 26

[Ere Maijala (slow)]

Comment on attachment 344394 [details] [diff] [review]
Rip out the broken code

I wasn't even aware of that code. Let's get this in and then try to come up with something that would allow us to properly steal the focus when appropriate.

Comment 27

[[e-mail]]

Pushed changeset 68472f4bb2ee to comm-central.