Closed Bug 216830 Opened 21 years ago Closed 16 years ago

cursor sticks (hangs up or freezes) when keying in message body data

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows ME
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: tophat39, Assigned: mscott)

Details

(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

When keying in text for a message, the cursor sporadically "hangs" up and will
not advance to the next character position. Repeated attempts jars it loose, but
it leaves an extra space (two spaces) instead of one before it continues.  In
all honesty, this could be a keyboard problem, but I do not have any problem in
Mozilla 1.4, Opera 7.11 or Outlook Express 6.0 with the cursor "sticking". 

Reproducible: Sometimes

Steps to Reproduce:
1. Start a new message by pressing the compose button.
2. Try entering normal alphanumeric data in the message body with HTML active.
3. Usually works fine, but tonight I loaded ver. 0.1 of TB and got the problem.



Expected Results:  
Normal typing and cursor movement should have occurred. Cursor should not have
"frozen" or "hung" in a sporadic fashion.
This behavior still exists in the 20030813 build.  I have even experienced the
cursor disapearing in conjuntion with it hanging.  Whole compose experince is an
exercise in slow motion.
I forgot to mention that this same sort of thing happens any time I have to type
something in using Thunderbird or Firebird; for example, this comment.  And as
noted by Ronald Killmer below, the cursor seems to disappear and then return, at
which poin t it is hung up.  Also, at the end of a line, the cursor will not
wrap to the next line properly (again, sporadically).  IMHO, this is something
that affects both Firebird and T hunderbird. I purposely left the unwanted
spaces in this text to show you what happens after you "kick" the cursor loose
(if you can!)
Additional Information based on continued observation during TB/FB usage:

The cursor is a vertical line which usually "blinks", but right before it is
going to "hang" or "freeze" the line becomes slightly wider and the cursor no
longer blinks. The cursor then freezes and you have to "somehow" kick it loose
(whatever works!) to be able to continue and not have to abort writing your
email, etc. I have used the spacebar, return key, ESC, etc. until I get
something to make it release the "deadly embrace" and resume proper operation. 
OS: Windows 98 → Windows ME
QA Contact: asa
I have also experienced this problem (in Windows 2000). Sometimes thunderbird 
stops responding to keystrokes completely. I can't reproduce the error in a 
deterministic fashion. It seems to occur at random times. Switching to other 
tasks, and back to composer seems to fix the problem.

Windows 2000
Thunderbird 0.4 Build (20031205)


All of my other programs respond to the keyboard reliably.
(In reply to comment #4)
> I have also experienced this problem (in Windows 2000). Sometimes thunderbird 
> stops responding to keystrokes completely. I can't reproduce the error in a 
> deterministic fashion. It seems to occur at random times. Switching to other 
> tasks, and back to composer seems to fix the problem.
> 
> Windows 2000
> Thunderbird 0.4 Build (20031205)
> 
> 
> All of my other programs respond to the keyboard reliably.

I wonder if we need to go through the TB forums. Seems I recall Scott MacGregor
wanting to work with forum input. Also, for me this is not just a TBird problem
, but a problem showing up in Moz 1.5, 1.6 FireFox 0.8....basically where ever 
text needs to entered...ie Yahoo mail, Excite mail or various other forms. I
never saw this anomaly until I left Moz 1.4.1.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 PentIII 128RAM  
I have only started noticing this behavior when I switched from Thunderbird 1.0 to 1.5rc1, and have also seen it in the 1.5 release.

1.0 never did this.

I switched to 1.5rc1 to get the realtime spell checking capabilities, and although I have no proof of this, I figured it might have had something to do with that.

Definitely while typing in composte windows, at random times, the cursor stops moving while I keep typing. After about 10 seconds control returns, and the keyboard buffer quickly catches up with what I typed. This is on a redhat9 machine, where I'd expect the X window manager to buffer up keystrokes while the app isn't responding.

Happens several times a day, and seems to have completely random occurance.
Also recently happens to me (but don't have details until I test more) with trunk build.
See also bug 218975.

Please cc: yourself on the bug if you comment and want to see future comments.
Severity: normal → major
Keywords: perf
I suspect it has something to do with the spellchecker.

If I paste several KB of text, the composer becomes unresposive and uses 100% CPU for a very very long time. Disabling spellcheck solves that problem. Today I had the unresponsive cursor problem, and the spellchecker is on.

Can anyone confirm that the spellchecker is on when the cursor hangs?
Has anyone seen a hanging cursor without spellchecker?

version 1.5.0.10 (20070306)
QA Contact: message-compose
Gunstick, I don't see this any more in version 2 or with trunk build. Do you?
In effect I currently use 2.0.0.6 (ubuntu 7.10) and I cannot reproduce the problem. 
this is also WFM version 3.0a1 (2008050715)

=> WFM
please comment if  you see otherwise
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
I know how to recreate the bug (I use Thunderbird 2.0.0.16, but I would assume this would work for everything).

In Thunderbird, hit 'Write' and tab to the message body. Type the following exactly (minus the dashes): c-a-n-t-spacebar-leftarrow-leftarrow-apostrophe-rightarrow-spacebar. You know have the bug.

To get rid of it, at the end of a word type: spacebar-backspace-spacebar. It's now gone.

You need to log in before you can comment on or make changes to this bug.