Closed Bug 195798 Opened 21 years ago Closed 21 years ago

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

Categories

(MailNews Core :: Composition, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: sspitzer)

References

Details

(Keywords: regression, Whiteboard: [adt2])

Attachments

(1 obsolete file)

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.
cc neil, as he's been checking into the compose / editor js-xul lately.
Assignee: ducarroz → sspitzer
Keywords: regression
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.
I see it on win32 (win2k)
could this have been caused by #192013?
this wasn't caused by neil's checkin for bug #192013

I backed it out locally, and it still occurs.
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.
I doubt it was me. I think this is an old bug, probably a dup.
we have created 2 caret objects in mail editor window.
maybe it is a clue
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.
This looks to me like a focus race. I either get 2 carets, or no carets, and
this has happened in the past.
I'm trying to back out bryner locally.

I agree with sfraser that we've seen this in (and fixed it) in the past.
Status: NEW → ASSIGNED
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)
Mail triage team: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
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
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.
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?
Attached patch patch for caret enabling (obsolete) — Splinter Review
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.
Attachment #117425 - Flags: superreview?(sfraser)
Attachment #117425 - Flags: review?(jfrancis)
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
Yes, that would make my patch unnecessary.
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.
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.
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?
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.
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 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.
I'm going to take a look at the WM_ACTIVATE(WA_INACTIVE) thing.
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...
I'm going to add a fix for the WM_ACTIVATE on Windows. The rest is in bug 189085.
Depends on: 35296
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 200255 has been marked as a duplicate of this bug. ***
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.
QA Contact: esther → sairuh
Comment on attachment 117425 [details] [diff] [review]
patch for caret enabling

obsoleted by checkin for bug 35296
Attachment #117425 - Attachment is obsolete: true
Attachment #117425 - Flags: superreview?(sfraser)
Attachment #117425 - Flags: review?(jfrancis)
yep, works with 2003.04.03 comm trunk builds.
Status: RESOLVED → VERIFIED
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?
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: