Closed Bug 173769 Opened 22 years ago Closed 22 years ago

Can't type in the compose window without clicking if sig present

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 173818
Milestone:
mozilla1.2beta

People

(Reporter: hacksoncode, Assigned: vparthas)

References

Details

(Keywords: access, regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021009
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021009

When I reply to a message (using the latest nightly, but not before) I can't
type anything until I click in the message window. The caret is flashing in the
message text window, but nobody's home.

Also, perhaps related, if I compose a new message (using CTRL-N), the first
character I type vanishes and the caret moves down one line.

Reproducible: Always

Steps to Reproduce:
1. Reply to a message.
2. Try to type without clicking in the message window.
3.

Actual Results:  
No text appears.

Expected Results:  
Text should appear when typing.
I can type when replying with 2002101108-trunk/Linux.
But when composing a new message, I can't type until clicking
the message pane.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
In a mail account without the signature, I can type normally.
However, in an account with the signature I cannot type.
I confirmed on 2002101305-trunk/linux.
confirm for win2k, build ID 2002101308
Composing new message without sig works without click,
replying does not work without click
Reassign to varada, Probably a regression caused by Editor API recent changes
Assignee: ducarroz → varada
Target Milestone: --- → mozilla1.2beta
Possible dup of bug 173818?
Tabbing into the composition area does not activate either. An actual mouse
click is required in the composition area to allow typing. Not just first
character. No typing happens at all no matter how much you type until you click
in the composition area.

Changing summary.
Summary: Can't type in the compose window on reply without clicking → Can't type in the compose window without clicking if sig present
On what platforms has Jerry Baker's behavior (no characters work until a click)
been seen?  The original problem reported in this bug (first character typed
doesn't work, subsequent ones do) is covered by bug 173818, and is reproducible
on all platforms AFAIK) but the behavior Jerry describes is something else,
perhaps not even related (maybe a focus problem).
Confirming Jerry Baker's behavior (comment #6) with 2002101608 on Win2k.
My description in the initial report was intended to describe both behaviors.
Both happen on WinXP with the originally reported build. 

I will say that with build 2002101508, I can't seem to reproduce the "first
character disappears" part of the bug, but I'm not entirely sure I remember how
I got that to happen originally, so that may be bogus. 

The "can't type at all until clicking" clarified in comment 6 still happens in
that later build on my machine.
*** Bug 174711 has been marked as a duplicate of this bug. ***
Anyone who's seeing this, please report more details of your prefs: html vs
plaintext, reply-above vs. reply-below vs. select, autoquote vs. not, signature
(plain or html), and does it matter whether you're replying to plain or html?. 
As far as I can tell, no one with a debug build has been able to reproduce this,
and it's still unclear whether this is a focus bug, editor bug, mail window bug,
or what.  

If anyone with a build can reproduce this, it would be good to know whether 
nsTextEditorKeyListener::KeyPress is ever being called, and also where the
selection is in the last nsTypedSelection::Collapse before you type a character.
It also might be worth trying the patch in bug 173818 to see if it helps.
Akkana: Sure thing.

* Plaintext (specifically: Send Format -> Convert to Plain text)
* Reply-below (though this just seems to occur on new messages)
* Autoquote?
* Signature: yes, plaintext
* Replying to plain or HTML: both are fine. (new messages seem to trigger it)
Mozilla is set to ask me what to do if I send an HTML message. It is set to use
the plaintext composer, and I have a one-line sig file. Unchecking the signature
box causes compose to behave correctly. This happens with new messages and not
with replies. I think focus is in the correct place because the cursor is
blinking there after tabbing into the compose area.
Plain text, reply above, no signature.
* autoquote
* plaintext
* reply below
* plaintext signature

Using build 20020101508 on Win2k.
Keywords: access
autoquote
plaintext
reply above
plaintext signature

Happens on replys or new messages. Using build 20020101508 on WinXP.

Turns out, I have a (quite reliable) mechanism for determining what window
handles have received the focus, and the result is rather odd (though it doesn't
really point to a problem with the location of the focus):

Upon creating the Compose window with Ctrl-M, the focus goes to Window 70238
(the top level compose window) and then immediately shifts to 70212. When
tabbing to the editor window, focus changes to 1002AA, but typing doesn't work.
When I click on the editor window, the focus does not change, but typing now
works. There's a chart of the window handle hierarchy at the bottom of this report. 

If I minimize and restore the compose window (without clicking), when I restore,
the focus is on window 70238, but typing still doesn't work. When I click on the
window now, it doesn't change the focus (still the top level window), but typing
now works. 

If I simply point Spy++ at what "looks like" the editor window, I get yet
another window handle: 1602E2, which turns out to be a child of the window I get
when tabbing to editor (1002AA).

Unfortunately, since all of Mozilla's windows seem to have the same Window
Class, that makes it hard to track down which windows are which with Spy++. But
for reference, the entire window hierarchy of the compose window looks like:

70238 (top level compose window)
  70212 (focus stops here when creating the Compose Window)
    41013E
    B03CE
      1002AA   (moves here on tabbing to editor)
        1602E2  (what Spy++ says if you drag the "find" tool to the editor)
    70384

Thanks for all the info.  Sounds like the necessary elements are:
- Windows (various versions)
- Plaintext compose window
- Plaintext signature
Some people see it only in new messages, some only in replies.
Cc bryner -- there may be something horked in the focus code on windows.

I'd guess this happens if something (signature or quote) is inserted to the
editor (possibly below the caret position) when it's started.
*** Bug 174624 has been marked as a duplicate of this bug. ***
Found another little tidbit of possibly clueful information: If I create a email
message, type in an address and a subject, and then save that email as a
template without typing any text, then when I double click on that template,
there's a blinking caret in *both* the subject line *and* the editor area. Also,
typing doesn't work without clicking.

However, if I create a template that *does* have text in the editor, above the
signature, then when I double-click on this template, I *can* type without clicking.

In both cases, though, the template is stored with a signature attached to it,
so of course there's text in the editor window in both cases. But only the
template where there's text that I *typed* after clicking in the original
composition window works. 
*** Bug 174952 has been marked as a duplicate of this bug. ***
*** Bug 175119 has been marked as a duplicate of this bug. ***
Now WFM with 2002101808. I have a speculation that this might be indirectly
caused by bug 171441, which I worked around by deleting compreg.dat while
Bugzilla was not running. Several other bugs disappeared immediately when I did
this, but this one persisted until my next reinstall. 

I don't know many details about it, but in the abstract I can think of several
ways in which having a corrupted component registration during installation
might cause strange behavior in many parts of Mozilla, and this might also
explain why only some people have observed this bug, and why people installing
debug versions might be unable to reproduce it. 

Anyway, if someone else having this problem can close Mozilla, delete
compreg.dat, restart (so a new compreg.dat is created), and reinstall Mozilla
(preferably the same version you were having the problem with... I didn't save
my install files), that might shed some more light on this.
this was almost certainly a dup of 173818, which I fixed shortly before this bug 
disappeared.

I suppose its academic, but you think the first char moving down a line was
caused by the same thing that caused compose not to accept keyboard input at all
(even if it was 1,000 keys)?
Yes WFM, trunk build 2002101804. Marking as dup. Ok?

*** This bug has been marked as a duplicate of 173818 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
*** Bug 175574 has been marked as a duplicate of this bug. ***
verified
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.