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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: mrbkap, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: fixed1.8, regression)
Attachments
(1 file, 1 obsolete file)
2.09 KB,
patch
|
mrbkap
:
review+
bzbarsky
:
superreview+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•19 years ago
|
Keywords: regression
Assignee | ||
Comment 1•19 years ago
|
||
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
Assignee | ||
Comment 2•19 years ago
|
||
Blake, could you try this patch and see if it fixes it for you? Thanks.
Reporter | ||
Comment 3•19 years ago
|
||
Yes it does. I'm sorry for taking so long to test it.
Assignee | ||
Comment 4•19 years ago
|
||
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)
Flags: blocking1.8b4?
Comment 5•19 years ago
|
||
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+
Reporter | ||
Comment 6•19 years ago
|
||
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+
Assignee | ||
Comment 7•19 years ago
|
||
Checked in on trunk 2005-08-21 17:25 PDT (with comment 5 addressed)
Blocks: 296464
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Could this have caused the orange on Firefox balsa?
Flags: blocking1.8b4+ → blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4+
Assignee | ||
Comment 9•19 years ago
|
||
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
Assignee | ||
Updated•19 years ago
|
Attachment #193344 -
Flags: approval1.8b4?
Comment 10•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #193344 -
Flags: approval1.8b4? → approval1.8b4+
Updated•19 years ago
|
Flags: blocking1.8b4rc?
Updated•19 years ago
|
Flags: blocking1.8b4rc?
Assignee | ||
Comment 11•19 years ago
|
||
*** Bug 304640 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•19 years ago
|
||
Checked in on MOZILLA_1_8_BRANCH at 2005-08-28 22:22 PDT ->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.
Description
•