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
I don't seem to see this on linux (latest trunk).
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
Uri: caused by bug 426766?
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?
Oops, wrong Neil. (how did that happen?)
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).
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...
Component: Message Compose Window → Composition
Product: Thunderbird → MailNews Core
QA Contact: message-compose → composition
Summary: Nav keys (arrows) inop on first change of composition mode → Broken focus (arrow keys, copy and paste don't work) in non-recycled compose windows
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...
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.
bug 459205 a dupe?
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?
Severity: normal → critical
(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.
Severity: critical → major
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. :)
(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.
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.
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.
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.
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 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 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.
Attachment #344394 - Flags: review?(emaijala) → review+
Pushed changeset 68472f4bb2ee to comm-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.