Closed Bug 304383 Opened 19 years ago Closed 19 years ago

Caret leaves turds when deleting the last character on a line

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: mrbkap, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file, 1 obsolete file)

If you delete the last character on a line, while the caret is visible, the
caret leaves a turd on the line. I suspect the checkin for bug 296464 is the
cause of this.

I think the reason for this is that when you delete the last character (note:
I'm talking about non-wrapped lines), the text frame the caret was in gets
deleted and is replaced with a BR frame, though I'm not certain.
Keywords: regression
Yeah, this seems to be a regression from bug 296464.
It's very hard for me to reproduce it though, so I wonder if I see the same
problem as you...
Assignee: mozeditor → mats.palmgren
Attached patch wip (obsolete) — Splinter Review
Blake, could you try this patch and see if it fixes it for you?  Thanks.
Blocks: 304640
Yes it does. I'm sorry for taking so long to test it.
Attached patch Patch rev. 1Splinter Review
Same thing, just added a comment. I'm guessing this fix won't be necessary if
bug 287813 makes the frame responsible for erasing the caret?
Attachment #192495 - Attachment is obsolete: true
Attachment #193344 - Flags: superreview?(bzbarsky)
Attachment #193344 - Flags: review?(mrbkap)
Comment on attachment 193344 [details] [diff] [review]
Patch rev. 1

No need to null-check aChild; in fact you can assert that it's non-null if you
want.
Attachment #193344 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 193344 [details] [diff] [review]
Patch rev. 1

I may have to make sure the parent repaints itself in this case, but I'm not
sure yet.

r=mrbkap
Attachment #193344 - Flags: review?(mrbkap) → review+
Checked in on trunk 2005-08-21 17:25 PDT (with comment 5 addressed)
Blocks: 296464
Flags: blocking1.8b4? → blocking1.8b4+
Could this have caused the orange on Firefox balsa?
Flags: blocking1.8b4+ → blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4+
I don't think so, FF/balsa had one green block containing my change.
The block after that was red:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1124672160&maxdate=1124682239

the next block fixed that but from here on it's orange:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1124682240&maxdate=1124702519

So it's either of those checkins above, looking at the crash log:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1124702520.17969.gz

my guess would be bug 303725
Attachment #193344 - Flags: approval1.8b4?
I don't know if this is known, but this bug also appear(s/ed) in the Windows
build as well.  Might have been fixed, but this was a multi-OS bug.
Attachment #193344 - Flags: approval1.8b4? → approval1.8b4+
Flags: blocking1.8b4rc?
Flags: blocking1.8b4rc?
No longer blocks: 304640
*** Bug 304640 has been marked as a duplicate of this bug. ***
Checked in on MOZILLA_1_8_BRANCH at 2005-08-28 22:22 PDT

->FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
OS: Linux → All
Resolution: --- → FIXED
Verified FIXED on trunk using build 2005-09-01-05, Windows SP SeaMonkey.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: