195798 - cursor appears in both address field and compose area for new mail compose windows

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[sairuh (rarely reading bugmail)]

cursor appears in both address field (To) and compose area for new mail compose
windows. focus is actually in the To field.

to observe:

open a new mail compose window (ctrl+M on win32/linux, cmd+shift+M on mac OS X
--or click the Compose button in mailnews 3pane).

watch how the cursor blinks in both the To address field and the main compose area.

occurs in both plaintext and html mail compose.

Comment 1

[(not reading, please use [e-mail] instead)]

cc neil, as he's been checking into the compose / editor js-xul lately.

Comment 2

[sairuh (rarely reading bugmail)]

i often see this when it's the first time (during a session) i bring up the mail
compose window.

this regressed btwn 2003.02.27.09 (works fine) and 2003.02.28.10 (broken), when
using mac os x bits.

Comment 3

[(not reading, please use [e-mail] instead)]

I see it on win32 (win2k)

Comment 4

[(not reading, please use [e-mail] instead)]

could this have been caused by #192013?

Comment 5

[(not reading, please use [e-mail] instead)]

this wasn't caused by neil's checkin for bug #192013

I backed it out locally, and it still occurs.

Comment 6

[(not reading, please use [e-mail] instead)]

simon, could this have been your fix for bug #74404: "show caret drag feedback"?

I'll try to back you out locally and see if it was that.

Comment 7

[Simon Fraser [no longer active]]

I doubt it was me. I think this is an old bug, probably a dup.

Comment 8

[leon.zhang]

we have created 2 caret objects in mail editor window.
maybe it is a clue

Comment 9

[kinmoz]

I think sfraser's off the hook, I backed out his changes in my TRUNK build from
today and though it took a little bit more effort, I was still able to get into
the situation  where we had 2 blinking carets.

Here's the list of checkins within the window se pointed out above:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=02%2F27%2F2003++08%3A00%3A00&maxdate=02%2F28%2F2003+10%3A00%3A00&cvsroot=%2Fcvsroot

I'd probably try backing out bryner's xbl changes next to see if that has any
effect.

Comment 10

[Simon Fraser [no longer active]]

This looks to me like a focus race. I either get 2 carets, or no carets, and
this has happened in the past.

Comment 11

[(not reading, please use [e-mail] instead)]

I'm trying to back out bryner locally.

I agree with sfraser that we've seen this in (and fixed it) in the past.

Comment 12

[(not reading, please use [e-mail] instead)]

backing out bryner didn't fix it.

sfraser wrote: "I either get 2 carets, or no carets"

I see that too, and it appears that I get 2 for a non-cached compose window, and
none for a cached compose window.

(see http://www.mozilla.org/mailnews/arch/compose/cached.html)

Comment 13

[Samir Gehani]

Mail triage team: nsbeta1+/adt2

Comment 14

[Alonso Acuña]

Still happens on Linux with march 11th build.
I wonder if this old unconfirmed bug has something to do with this: 180774
Another unconfirmed old bug that may be related: 186104

Comment 15

[Brian Ryner (not reading)]

One thing I'm seeing is that even though the editor is never focused, code in 
editor assumes that it should enable the caret during initialization.  I see 
it with this stack:

PresShell::SetCaretEnabled(PresShell * const 0x03d761b8, int 1) line 3125
nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x03b608d4, int -1, short 
0) line 374
nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x0341e510) line 4354 + 62 
bytes
nsAutoRules::~nsAutoRules() line 126
nsTextEditRules::CreateBogusNodeIfNeeded(nsISelection * 0x0328afe0) line 1287 
+ 25 bytes
nsTextEditRules::Init(nsTextEditRules * const 0x03b608d4, nsPlaintextEditor * 
0x0341e510, unsigned int 64) line 148 + 17 bytes
nsHTMLEditRules::Init(nsHTMLEditRules * const 0x03b608d4, nsPlaintextEditor * 
0x0341e510, unsigned int 64) line 229 + 17 bytes
nsHTMLEditor::InitRules(nsHTMLEditor * const 0x0341e510) line 505 + 40 bytes
nsPlaintextEditor::EndEditorInit() line 249 + 15 bytes
nsAutoEditInitRulesTrigger::~nsAutoEditInitRulesTrigger() line 160 + 18 bytes
nsHTMLEditor::Init(nsHTMLEditor * const 0x0341e510, nsIDOMDocument * 
0x032c2384, nsIPresShell * 0x03d761a8, nsIContent * 0x00000000, 
nsISelectionController * 0x03d761b8, unsigned int 64) line 360


and then again with this stack:

PresShell::SetCaretEnabled(PresShell * const 0x03d761b8, int 1) line 3125
nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x03b608d4, int 4, short 1) 
line 374
nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x0341e510) line 4354 + 62 
bytes
nsAutoRules::~nsAutoRules() line 126
nsEditor::CreateNode(nsEditor * const 0x0341e510, const nsAString & {...}, 
nsIDOMNode * 0x03b3f6e4, int 0, nsIDOMNode * * 0x0012dfa8) line 1152 + 14 bytes
nsPlaintextEditor::SetDocumentCharacterSet(nsPlaintextEditor * const 
0x0341e510, const nsAString & {...}) line 322 + 79 bytes
nsMsgCompose::InitEditor(nsMsgCompose * const 0x03e720c0, nsIEditor * 
0x0341e510, nsIDOMWindow * 0x03d5079c) line 1267

I see this behavior when the compose window is uncached, the first time I 
bring it up.  After we enable the caret for the compose area via the stacks I 
pasted above, we focus the addressing widget.  That doesn't trigger any blur 
listeners for the compose area because it was never focused in the first place 
(and shouldn't have been showing a caret).

I don't see this when I bring up the window again, presumably because the 
editor is already intialized in the cached compose window.  I do see a 
sporadic problem on subsequent attempts where _no_ carets appear; I'll try to 
figure out what's going on there.

Comment 16

[Brian Ryner (not reading)]

cc'ing jfrancis who added that call to SetCaretEnabled(PR_TRUE) from 
nsHTMLEditRules::AfterEdit way back in January of 2000 (rev 1.84 of 
nsHTMLEditRules.cpp).  Joe, do you know why we'd need to unconditionally 
enable the caret there even if the editor document doesn't have focus?

Comment 17

[Brian Ryner (not reading)]

Attachment: patch for caret enabling

We could do something like this, where we store the caret state before we hide
it in BeforeEdit, and restore the previous state in AfterEdit.	This fixes the
dual carets for me, but not the problem where sometimes there's no caret.

Comment 18

[leon.zhang]

hi,Brian
I think new patches for bug 35296 can resolve this bug.
If you delete codes related to tun on/off caret in
nsHTMLEditRules::After/BeforeEdit, this bug will also disappear.

I reason why delete these codes is that it happened before reflow and draw caret
a incorrect position.

 see comments below:
http://bugzilla.mozilla.org/show_bug.cgi?id=35296#c46
http://bugzilla.mozilla.org/show_bug.cgi?id=35296#c47
http://bugzilla.mozilla.org/show_bug.cgi?id=35296#c48

newest patch for that bug is:
http://bugzilla.mozilla.org/attachment.cgi?id=117393&action=view

Comment 19

[Brian Ryner (not reading)]

Yes, that would make my patch unnecessary.

Comment 20

[Brian Ryner (not reading)]

I believe the reason that no caret appears occasionally is that if an input
field was focused when the window was closed, and the window is cached, the
'focused' attribute is never removed from the xul textbox, so it ignores the
focus() the next time the window is shown.

I'm thinking when a window is hidden maybe we should send a blur event, as if
the user blurred the toplevel window.  CC'ing danm, master of all things windowy
and blurry.

Comment 21

[[e-mail]]

I can duplicate Brian Ryner's missing caret test case, but I'm not convinced
about the cause, because IIRC that particular node is recreated every time.

Comment 22

[Brian Ryner (not reading)]

neil, I arrived at that conclusion by adding some dump statements to the focus
handler in textbox.xml and noting that the focused attribute was already set
when it was called for the second showing of the window.  Is there some other
way you think it's getting set?

Comment 23

[[e-mail]]

bryner, my issue is that if I save the addressCol2#1 element then when I close
and open the window the saved element isn't the one displayed, and I haven't had
time to figure out where that one is coming from yet.

Comment 24

[sairuh (rarely reading bugmail)]

other likely versions of this bug:

bug 197325: midas showing cursor in textarea even though focus isn't there
bug 197502: find as you type triggered in midas upon initial page load

Comment 25

[Dan M]

(comment 20:) On Windows at least the WM_ACTIVATE(WA_INACTIVE) message you'd
expect to get when the Compose window is hidden has recently gone missing. See
bug 189085 comment 37.

Comment 26

[Ere Maijala (slow)]

I'm going to take a look at the WM_ACTIVATE(WA_INACTIVE) thing.

Comment 27

[[e-mail]]

Another way I can make a cursor appear in the compose area is to change the
identity to one with a signature, although the focus really remains on the
identity picker.

Also, the reason I was having trouble duplicating bryner's issue is that if you
replace a node with its clone the blur and xbl destructor don't fire on the old
element :-( so I wasn't sure if it was the focused node that had been cloned...

Comment 28

[Ere Maijala (slow)]

I'm going to add a fix for the WM_ACTIVATE on Windows. The rest is in bug 189085.

Comment 29

[leon.zhang]

patch for bug 35296 has been checked in, I cannot reproduce this bug, so close it.
If you have new thought, you can reopen it.

Comment 30

[Patrick]

*** Bug 200255 has been marked as a duplicate of this bug. ***

Comment 31

[(not reading, please use [e-mail] instead)]

I don't see this problem anymore on my debug, win32 bits.

so maybe bug #35296 fixed it?

let me re-assign to sarah (who logged it) to verify.

Comment 32

[Brian Ryner (not reading)]

Comment on attachment 117425 [details] [diff] [review]
patch for caret enabling

obsoleted by checkin for bug 35296

Comment 33

[sairuh (rarely reading bugmail)]

yep, works with 2003.04.03 comm trunk builds.

Comment 34

[Patrick]

I haven't paid attention to this one for a long time [which means it is indeed
fixed ;)] however today i noticed that if i press COMPOSE, for a VERY brief
instant still two cursors are shown: one in the TO field and one in the body of
the message. The latter vanishes quickly and the TO field gets focus.

So it seems like it's not a fully optimized fix [a cursor is created in the
body, only to disappear again].

Anyone else seeing this?