I am running SeaMonkey 1.5a, (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a I recently upgraded to that from 20070219, and have frequently noticed a new problem in the plain text mail composer that I did not notice with the 0219 build. Frequently, as I am composing email, the compose window stops responding to any keyboard input. You click on an editable place in the compose window and type, but NOTHING happens. keyboard input still works in other windows, such as the browser address bar, and in other applications, but not in the mail composer window. Also, occasionally (somewhat less frequently than the above problem), it stops responding to both keyboard AND MOUSE inputs. When that happens, I can no longer move the scroll thumb up and down, cannot select (highlight), Clicking on the menu bars and action buttons have no effect. I'm stuck. When either of these problems occurs, there is a simple remedy. Clicking on another application window (not another SeaMonkey window) and then clicking again on the SeaMonkey composer window restores the composer window's ability to process keyboard and mouse input ... for a while, until it happens again. I have not been able to determine any specific sequence of activities that leads to this problem, but I encounter it at least once an hour. (I spend a lot of time composing email daily.)
I think this is a symptom of bug 372177.
The behavior demonstrated in bug 372177 is very similar indeed to the problem I reported here of not responding to the keyboard. I was not able to reproduce the case of "lost" keyboard and mouse inputs with the demo in that bug. So, this bug isn't exactly a duplicate, because this bug also reports lost mouse inputs.
Well, that last comment of mine was about as clear as mud. I'll try again. Using the technique described in bug 372177, I am able to recreate, at will, the first symptom I reported above, wherein the mail composer stops responding to keyboard input, but continues to respond to the mouse. Basically, it's as simple as - open the mail window, - open a mail composer window, - bring the mail window to the foreground, then - minimize the mail window, revealing the compose window as the top window underneath the mail window. The compose window is then in that state. However, using that technique, I am unable to reproduce the symptom where the composer stops responding to both keyboard and mouse input. Yet I continue to experience that symptom daily. So, maybe there are two separate problems here which can occur at the same time, one affecting keyboard events, and one affecting mouse events. I will continue to try to see if I can determine what sequence of events causes the loss of mouse input. I wish I had some sort of event recorder that might enable me to replay (or at least re-read) my actions prior to the loss of mouse input.
Bug 372177 was fixed in march, and I do not recall seeing the problem of a window ceasing to respond to keyboard events since then. But the problem of a window ceasing to respond to mouse clicks is definitely still experienced in 20050418. Now I am using 20050525, and I will see if I experience it there also, or not.
Still occurring on trunk. Seems this problem always occurs when I'm not trying to reproduce it. So, when it happens, I don't remember the immediately preceeding 10-20 clicks and keystrokes, and what order they were done it. I wish I had some kind of recorder that could capture all my keystrokes and clicks until it occured
Summary: email composer stops responding to keyboard and mouse input → email composer stops responding to mouse input
Nelson do you still see this? I don't on trunk vista and XP.
I don't recall seeing this for several months now. I guess it can be resolved worksforme.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.