Closed
Bug 304383
Opened 20 years ago
Closed 20 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•20 years ago
|
Keywords: regression
| Assignee | ||
Comment 1•20 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•20 years ago
|
||
Blake, could you try this patch and see if it fixes it for you? Thanks.
| Reporter | ||
Comment 3•20 years ago
|
||
Yes it does. I'm sorry for taking so long to test it.
| Assignee | ||
Comment 4•20 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•20 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•20 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•20 years ago
|
||
Checked in on trunk 2005-08-21 17:25 PDT (with comment 5 addressed)
Blocks: 296464
Updated•20 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•20 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•20 years ago
|
Attachment #193344 -
Flags: approval1.8b4?
Comment 10•20 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•20 years ago
|
Attachment #193344 -
Flags: approval1.8b4? → approval1.8b4+
Updated•20 years ago
|
Flags: blocking1.8b4rc?
Updated•20 years ago
|
Flags: blocking1.8b4rc?
| Assignee | ||
Comment 11•20 years ago
|
||
*** Bug 304640 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 12•20 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
•