Focus freezes in addressing envelope

RESOLVED DUPLICATE of bug 215771

Status

RESOLVED DUPLICATE of bug 215771
15 years ago
15 years ago

People

(Reporter: mscott, Assigned: Bienvenu)

Tracking

unspecified
Thunderbird0.2
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.2
(Assignee)

Comment 1

15 years ago
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?
(Reporter)

Comment 2

15 years ago
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.
(Assignee)

Comment 3

15 years ago
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

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

Updated

15 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 5

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

Comment 6

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

Comment 7

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

Comment 8

15 years ago
taking for investigation
Assignee: scott → bienvenu
Status: ASSIGNED → NEW
(Assignee)

Comment 9

15 years ago
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.
(Assignee)

Comment 10

15 years ago
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
(Assignee)

Comment 11

15 years ago
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
(Assignee)

Comment 12

15 years ago
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.
(Reporter)

Comment 13

15 years ago
Good News! It looks like Brian's fix in Bug #215771 fixed this issue for us.
(Reporter)

Updated

15 years ago
Depends on: 215771
(Assignee)

Comment 14

15 years ago
dup of 215771

*** This bug has been marked as a duplicate of 215771 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 15

15 years ago
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.