310227 - Deleting characters with backspace makes the caret disappear in Editor and textareas

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Tobias Fischer]

Using 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050927
SeaMonkey/1.1a Mnenhy/0.7.2.10010 {Build ID 2005092706}

deleting some Charakters in MailNews Editor while compose Message let Caret
desapear. Write on reanimate Caret in most cases after type the same Number of
deleted Charakters. This was first seen in Build 2005092704 by Rüdiger Lahl
<[e-mail]> 

Reproduceable: always

Steps to reproduce:
1. Start to compoe a Message
2. type some text in Message Body
3. Delete some Charakters using Backspace

Actual Results:
when write on, Caret has disapeared mostly for the number of deleted Charakters
Also while file this Bug here, the Caret was invisible after I have deleted some
Charakters. Possible regression from Checkin for Bug 308023?

Comment 1

[Uri Bernstein]

I'm looking into this. I can reproduce the bug with the 2005-09-27 SeaMonkey
build. However, I do not see the bug with my own Firefox build, which contains
the fix to 308023 - so I'm not sure it's a regerssion from that fix. I'll keep
investigating.

Comment 2

[Uri Bernstein]

I verified that this is NOT a regression from 308023 by getting the latest
sources, compiling, reproducing the bug - then backing out 308023, recompiling -
and the bug is still there.

I'll continue investigating this tomorrow (unless someone else figures it out by
then).

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Could it be bug 307875, then?

Comment 4

[Uri Bernstein]

(In reply to comment #3)
> Could it be bug 307875, then?

Yes, backing out the patch for 307875 does fix this.

Comment 5

[Hixie (not reading bugmail)]

This is surprisingly annoying.

Comment 6

[rbs]

Investigating....

Comment 7

[Adam Guthrie]

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

Comment 8

[rbs]

Attachment: bring the caret back - take 1

This patch restores the caret by resetting |mDrawn| when the caret is erased.
Since poking into dirty frames is blocked, there are early returns causing it
not to be reset.

The real underlying effect is that the next nsCaret::DrawCaret() will refetch
the frame & offset (which are up-to-date by the time the caret is redrawn).
http://lxr.mozilla.org/mozilla/source/layout/base/nsCaret.cpp#862

However... we are back to bug 304383. Wwhen you delete the last character,
there is a character-data-changed, which marks the frame dirty. Then comes a
content-removed (since it was the last char), and the hack added in bug 304383
to erase the caret has no effect. That hack does not work anymore because of
the early returns (due to the frame being dirty).

Comment 9

[rbs]

Attachment: bring the caret back - take 2

Disable one of the early returns that affect the caret.

The caret holds a lastcontent & lastoffset (I noted that it used to hold a
frame but this was changed to fix similar out-of-sync issues in bug 296464).
The caret needs them to erase itself from its old location.

[Since the frame can become out-dated, why not just keep the old rect. This
way, the caret won't have to figure out where it used to be based on old
frame/content/offset that could change under its feet. I hope folks reworking
the caret in bug 287813 will think carefully through these things.]

Comment 10

[rbs]

Attachment: bring the caret back - take 3

Take a breadth by disabling those early returns that are causing troubles so
far.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 197968 [details] [diff] [review]
bring the caret back - take 3

Could also leave them on in debug builds so people see the asserts... (and
those _are_ asserts, right?)

Comment 12

[rbs]

Checked in.

OK, I moved the #if 0 after the DEBUG_VERIFY test so that people (who have added
themselves in the DEBUG_VERIFY test) can see the warning messages.

NS_WARNING is not an assert or Windows. The real assert (NS_ASSERTION) is harsh
(on Windows). It can be quite painful if it occurs a lot because each assert
pops up a modal dialog and possibly breaks into the debugger. You have to click
OK at each keystroke to get rid of the dialog box.

Comment 13

[Adam Guthrie]

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

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 15

[Magnus Melin [:mkmelin]]

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

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2005-10-03-05 of trunk SeaMonkey running on XP.