214408 - Focus freezes in addressing envelope

Status: RESOLVED DUPLICATE of bug 215771

(Thunderbird :: Message Compose Window, defect)

Description

[Scott MacGregor]

This probably happens in seamonkey mail too. 

Sometimes when you bring up a compose window and start adding addresses, focus
freezes in the compose window and you cannot add a new recipient.

WORK AROUND: for now, just move focus out of the addressing envelope. i.e. click
on the message body then back in the addressing envelope.

We need to fix this for the next Thunderbird milestone.

Comment 1

[David :Bienvenu]

I don't see this in debug builds - I may have seen it once in a release build.
Does this happen with replies, or new msg, or both?

Comment 2

[Scott MacGregor]

I can still trigger this in the latest release builds.

The trick is to type an address. hit return. then back space on the next line.

I'll have to try a debug build.

Comment 3

[David :Bienvenu]

ah, yes, that's the trick. It does happen in debug builds, but I didn't see
anything interesting on the console. I can put this on my list if you want.

Comment 4

[Calum Mackay]

I see this every time I delete an address; linux/x86 20030818.

Comment 5

[Calum Mackay]

*** Bug 216297 has been marked as a duplicate of this bug. ***

Comment 6

[Calum Mackay]

that was a Seamonkey bug I just duped; definitely happens there too, for me on
linux/x86 20030818.

Comment 7

[samuel]

see duplicate bug 216297 for how to reliably reproduce the bug (at least, on my
RH9 box)

Comment 8

[David :Bienvenu]

taking for investigation

Comment 9

[David :Bienvenu]

In the js debugger, in addressingWidgetOverlay.js, we're getting all the way to
    top.awInputElement.focus(); in _awSetFocus, so I don't think this is a
problem in the address widget per se, but something underlying.

Comment 10

[David :Bienvenu]

I've stepped into the event state manager code, which is where I suspect the
problem is. I don't know if this is related or not, but it's deleting the last
character in the address field that sets the focus to null, not pressing
backspace with an empty address field - here's the stack trace

nsEventStateManager::SetFocusedContent(nsEventStateManager * const 0x07581b28,
nsIContent * 0x00000000) line 4338
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x07581b28,
nsIPresContext * 0x05a21030, nsEvent * 0x0012f59c, nsIFrame * 0x05b0ab88,
nsEventStatus * 0x0012f3c8, nsIView * 0x05a70698) line 830
PresShell::HandleEventInternal(nsEvent * 0x0012f59c, nsIView * 0x05a70698,
unsigned int 0x00000001, nsEventStatus * 0x0012f3c8) line 6205 + 49 bytes
PresShell::HandleEvent(PresShell * const 0x05a70c78, nsIView * 0x05a70698,
nsGUIEvent * 0x0012f59c, nsEventStatus * 0x0012f3c8, int 0x00000001, int &
0x00000001) line 6106 + 25 bytes
nsViewManager::HandleEvent(nsView * 0x05a70698, nsGUIEvent * 0x0012f59c, int
0x00000000) line 2253
nsView::HandleEvent(nsViewManager * 0x05a704b8, nsGUIEvent * 0x0012f59c, int
0x00000000) line 305
nsViewManager::DispatchEvent(nsViewManager * const 0x05a704b8, nsGUIEvent *
0x0012f59c, nsEventStatus * 0x0012f50c) line 2036 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f59c) line 79
nsWindow::DispatchEvent(nsWindow * const 0x05a70744, nsGUIEvent * 0x0012f59c,
nsEventStatus & nsEventStatus_eIgnore) line 1050 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f59c) line 1071
nsWindow::DispatchFocus(unsigned int 0x0000006c, int 0x00000000) line 5387 + 15
bytes
nsWindow::ProcessMessage(unsigned int 0x00000008, unsigned int 0x001407e2, long
0x00000000, long * 0x0012f9f4) line 4151 + 23 bytes

Comment 11

[David :Bienvenu]

I suspect that the fix checked in for bug 53579 caused this regression - I'll
try backing it out locally to see.

Comment 12

[David :Bienvenu]

Interestingly, it wasn't until I backed out the view manager part of that patch
that this bug went away, in particular, these lines:

+        if (aEvent->message == NS_DEACTIVATE)
+          mMouseGrabber = mKeyGrabber = nsnull;
+

I had forgot to rebuild the view code after applying the patch, ran, and still
had this problem. After rebuilding everything with the view change backed out,
this bug went away. So, my guess is that we're never restoring/setting the
mMouse and mKeyGrabbers.

Comment 13

[Scott MacGregor]

Good News! It looks like Brian's fix in Bug #215771 fixed this issue for us.

Comment 14

[David :Bienvenu]

dup of 215771

*** This bug has been marked as a duplicate of 215771 ***

Comment 15

[samuel]

as of 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030829

my test case ( bug 216297 ) stil exhibits a problem 
(RH9 / KDE)