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.
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.2
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?
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.
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.
I see this every time I delete an address; linux/x86 20030818.
*** Bug 216297 has been marked as a duplicate of this bug. ***
that was a Seamonkey bug I just duped; definitely happens there too, for me on linux/x86 20030818.
see duplicate bug 216297 for how to reliably reproduce the bug (at least, on my RH9 box)
taking for investigation
Assignee: scott → bienvenu
Status: ASSIGNED → NEW
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.
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
I suspect that the fix checked in for bug 53579 caused this regression - I'll try backing it out locally to see.
Status: NEW → ASSIGNED
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.
Good News! It looks like Brian's fix in Bug #215771 fixed this issue for us.
dup of 215771 *** This bug has been marked as a duplicate of 215771 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
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)
You need to log in before you can comment on or make changes to this bug.