Open Bug 567240 Opened 10 years ago Updated 4 years ago

Cursor does not blink when replying

Categories

(MailNews Core :: Composition, defect)

defect
Not set

Tracking

(Not tracked)

REOPENED

People

(Reporter: u382332, Unassigned)

References

Details

(Keywords: access, regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100520 Minefield/3.7a5pre Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100519 Thunderbird/3.1 RC1

No blinking cursor when replying. This happens more often than not.

Reproducible: Always

Steps to Reproduce:
1.Reply to an email
2.If cursor is blinking, close that reply and click reply again or reply to another email.
3.
Actual Results:  
Cursor not blinking

Expected Results:  
Cursor should always blink
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100515 Lanikai/3.1pre, the 2nd opening of a reply shows a steady cursor rather than a blinking one. I couldn't get a case though where the cursor was in a hidden non-blinking state.

I couldn't reproduce it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 stable release, thus regression.

This happens with either plain-text or HTML composition.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
I also should have noted that the cursor is always visible, just not blinking.
A few additional observations:
Repeated replies from a standalone message window do not show this symptom
Reply from a tab or messagepane does.

Clicking on the subject or from pane will restart the blink after reselecting body

Confirming, and cc Mark as this might be related to current focus problems in core

Backed up to 20100513 build and the problem still there, so not a regression
from bug 543077 checkin, but possibly related to core>>focus issues.
Version: Trunk → unspecified
Also seen with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100520 SeaMonkey/2.1a2pre, so it looks indeed like a Core issue.
Component: Message Compose Window → Composition
Product: Thunderbird → MailNews Core
QA Contact: message-compose → composition
Version: unspecified → Trunk
Regression range:

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090610 Shredder/3.1a1pre
2009-06-10-03-comm-central-trunk

broken - cursor there but doesn't blink:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Shredder/3.1a1pre
2009-06-11-04-comm-central-trunk

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-06-10+02%3A00%3A00&enddate=2009-06-11+05%3A00%3A00

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-06-10+02%3A00%3A00&enddate=2009-06-11+05%3A00%3A00
(In reply to comment #3)

> Backed up to 20100513 build and the problem still there, so not a regression
> from bug 543077 checkin, but possibly related to core>>focus issues.

I didn't think the bug 543077 fix landed yet.  Is that statement correct or am I missing something?

Bug 543077 has the same regression range.
(In reply to comment #6)
> (In reply to comment #3)
> 
> > Backed up to 20100513 build and the problem still there, so not a regression
> > from bug 543077 checkin, but possibly related to core>>focus issues.
> 
> I didn't think the bug 543077 fix landed yet.  Is that statement correct or am
> I missing something?
> 
> Bug 543077 has the same regression range.

Yes, the fix was landed on the relbranch only.
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/df8af28774dc

So it probably was addressing a common core problem.
Bozz would you mind finding the regression date see http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ for a tutorial on how to do that.
(In reply to comment #8)
> Bozz would you mind finding the regression date see
> http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/
> for a tutorial on how to do that.

Isn't that what Matt has already done in [url=https://bugzilla.mozilla.org/show_bug.cgi?id=567240#c5]Comment 5[/url]?
Yes, June 10/11, 2009. This has been there for quite a while, guess I've never replied twice to the same message since...
(In reply to comment #9)
> (In reply to comment #8)
> > Bozz would you mind finding the regression date see
> > http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/
> > for a tutorial on how to do that.
> 
> Isn't that what Matt has already done in
> [url=https://bugzilla.mozilla.org/show_bug.cgi?id=567240#c5]Comment 5[/url]?

Yeah my bad I skipped the context :-( twice I do this this year.
oops meant to say reproduced in Thunderbird 3.1 RC2 on Windows 7 and Mac OS X 10.6.3
If anyone has some time, could you look into this bug further please. It has become increasingly annoying with the latest Shredder. The cursor does not blink for every reply now for me. Thanks.

Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100804 Shredder/3.2a1pre
Severity: normal → minor
Summary: No blinking cursor when replying → Cursor does not blink when replying
Did anybody encounter a case where the cursor wasn't blinking the "wrong" way, i.e., it stopped in the hidden state rather than the shown state?

Also, I'm setting the accessibility flag, considering that the blinking is a visual cue on the cursor position for visually impaired users.
Keywords: access
Blocks: 625729
if comment 5 hg links are correct, my money is on bug 178324 being the regressor. checkin neil@mozilla.com Wed Jun 10 11:01:37 2009 -0700 Bug 178324, refactor focus by moving all focus handling into one place and simplifying it, add many tests, fixes many other bug
Severity: minor → normal
Yes, this sounds like bug 178324 is at fault. Has anyone been able to repro this on Thunderbird nightlies based off of Gecko 2.0? Maybe that one will go away once Thunderbird moves to Gecko 2.0.
still exists in current TB nightly
Blocks: 178324
3.3 alphas are being released and this bug isn't getting fixed. Is this bug of no concern to anyone?
Severity: normal → blocker
Sorry, but even if this hasn't been getting the attention it maybe should have, it still isn't a blocker.

What we probably need is to see if we can come up with a testcase in Firefox. Then it'd be easier to file a core bug on it and get it fixed.
Severity: blocker → normal
Flags: wanted-thunderbird+
Is there anything I can do to help?
I am unable to reproduce this in Firefox.
(In reply to comment #21)
> What we probably need is to see if we can come up with a testcase in
> Firefox. Then it'd be easier to file a core bug on it and get it fixed.

As Bozz has stated in the original description, the problem (exclusively or predominantly?) occurs when replying to a message the second or more time.
Thus, any testcase for Firefox (or Editor in general) would have to mimic replying to a message and may have to contain specific triggering items.

Also, the regression range has been narrowed down in comment #5 to a single-day interval which should help getting the culprit identified and the issue fixed.
Actually this happens with every reply after the first reply after a clean start or restart of Thunderbird.

1. Launch or restart Thunderbird.
2. Reply to a message, the cursor is blinking properly.
3. Reply to another message, the cursor does not blink.
Still reproducible with yesterday's nightly 3.3a4pre build on Windows 7, and I also see it with the Linux x86_64 build, thus assuming cross-platform.

As an interesting observation on Linux, I see this on a per-message basis only. Thus, if I open a different message and reply to it, the cursor blinks again; if I reply to the same message for a second time, the cursor isn't visible for a split-second, then appears and stays. This is different from Windows.

If I change to a different message, it's blinking again. In a message where the cursor doesn't blink, it starts blinking after focusing the addressing pane and then going back to the message body. This also works on Windows 7.
OS: Windows XP → All
Hardware: x86 → All
> (comment #26) This is different from Windows.
> If I change to a different message, it's blinking again.

:-\ ...the first sentence of the third paragraph was supposed to go before the last sentence of the second paragraph, bad editing (with or without cursor).
> (...and here yet another addendum to comment #26) In a message where
> the cursor doesn't blink, it starts blinking after focusing the addressing
> pane and then going back to the message body. This also works on Windows 7.

This seems to be a key point. On Windows 7 (but not on Linux) I can get a non-blinking cursor when using "Edit As New" for the second time. Similar to "Reply", the initial placement of the cursor is in the message body, whereas "Forward" and "Write" place it in an address row on opening.

Following sequence with the same message:
 - Reply (blinking)
 - Reply (not blinking)
 - Edit As New (not blinking)
 - Forward (focus in address row)
 - Edit As New or reply (blinking)
 - Reply (not blinking)

Thus, "Forward" equally breaks the spell due to the focus change, and it also appears to be resolved when the reply was in HTML mode but Edit As New on a plain-text message opens the editor in plain-text mode. Hope this helps.
I've observed a couple of times now that the cursor "unblinks" in the other direction and disappears, also reported in http://gsfn.us/t/2dn7a on the GS forums. I don't know if it's related to the bug here, also given that it's apparently not as reproducible, but sure increases severity of the issue.
(In reply to rsx11m from comment #28)
Still reproducible in TB 8.0 on multiple machines with Windows XP SP3.
howdy y'all,

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

this still happens in tb901. STR is unchanged ...
- reply to any msg in either html or plaintext [cursor blinks]
- close the reply window or tab
- reply to any msg in either html or plaintext [cursor does NOT blink]

doing a forward or edit-as-new will re-enable cursor blinking until a reply is done twice in a row.

take care,
lee
I don't see anything posted here this year, but from my experience the bug still exists.

I'm running Win 7 Pro 64-bit. I actually just did a clean re-install of the OS and am gradually adding software back to the system. 

I downloaded Thunderbird 14. Now suddenly I'm experiencing the error everybody else describes above:
Reply to one message, get a blinking cursor.
Reply to a second message, the cursor doesn't flash. 

I'm happy to try out solutions if anybody cares to present possibilities.

Even though I had 14 installed before my system rebuild, I never experienced the problem. But for some reason it is happening now. 

I'm running the following add-ons:
Canadian English Dictionary 2.0.5
CompactHeader 2.0.6
ImportExportTools 2.7.2.2
Lightning 1.6
Test Pilot for Thunderbird 1.3.9 

Test Pilot is the only new element. I wasn't running it prior to the system wipe. I was running all of the other add-ons.
I wanted to mention that I'm happy to try out solutions if anybody cares to present possibilities.
Somewhere along the way, this bug seems to have resolved itself.

Tested and verified by community members over at MozillaZine.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Per http://forums.mozillazine.org/viewtopic.php?f=29&t=2699153
- last affected version: TB 16.0.2
- first no longer affected: 17.0b1

There is still one report on this issue happening on trunk, but not reproducible by anyone else in that thread on various platforms.

If someone here still sees this issue, please post a comment along with any specific information on your installation.
Does not work in TB 17.0.7
Please reopen. It *works* in 17.0.6 but does not work in 17.0.7 (and Earlybird 24).
Too bad, but I can reproduce with SeaMonkey 2.21a2 (corresponding to TB 24.0a2) with the original steps to reproduce (mail.compose.max_recycled_windows set to 1, in case it matters).

Reopening as it's still seen in a current build and the cause wasn't established.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to rsx11m from comment #38)
> Too bad, but I can reproduce with SeaMonkey 2.21a2 (corresponding to TB
> 24.0a2) with the original steps to reproduce
> (mail.compose.max_recycled_windows set to 1, in case it matters).
> 

It matters. Cannot reproduce with mail.compose.max_recycled_windows=0
Happens every time with str in comment 0 with that pref=1
Testing with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0a1 ID:20130712030204 CSet: 1474fbd5ab3d
howdy y'all,

i wonder if bug 881588 is related? it also is dependent on reusing the compose window. if so, then perhaps this is a new bug ...

take care,
lee
(In reply to Joe Sabash from comment #39)
> It matters. Cannot reproduce with mail.compose.max_recycled_windows=0
> Happens every time with str in comment 0 with that pref=1

Yep, I can confirm that for TB 24.0.1. With that pref=0 it never happend with pref=1 it always happens.
Still in TB 38.0.1
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
You need to log in before you can comment on or make changes to this bug.