Closed Bug 39469 Opened 25 years ago Closed 22 years ago

deleting text leaves visual garbage behind

Categories

(Core :: DOM: Editor, defect, P4)

defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: cmaximus, Assigned: kinmoz)

References

Details

(Keywords: helpwanted, Whiteboard: [nsbeta3-][p:4][minus])

***Overview Description: This is fairly straightforward to see (now that we have a Mac Build) Insert some text in a compose window(I used Debug| Insert some text) and then start tapping away on the delete key. ***Steps to Reproduce: 1) Noted above. ***Actual Results: Most of the deleted character remains. Some is removed and the cursor backs up. Forcing the window to redraw will remove the cruft. ***Expected Results: Deleted characters should just go away! ***Build Date & Platform Bug Found: Discovered via smoktesting on the 2000051609 build. Not a probelm on other platforms.
assigning to Kin for debugging
Assignee: beppe → kin
Target Milestone: --- → M17
Accepting bug.
Status: NEW → ASSIGNED
I see a similar (same?) problem when I am typing. The entire text is not rendered. It seems to get worse (less is drawn) as I type more text across the window. When I get to the right edge, I may be missing the last 2 or 3 characters I've typed (which do show up if you force a repaint).
setting to nsbeta3
Keywords: correctness, nsbeta3
Target Milestone: M17 → M18
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]
adding buster to cc list, Steve -- Kin will need your help on this one, do you have any free cycles to help?
Buster, I think this is caused by characters like 'f' that seem to draw outside the frame bounds ... does the nsTextFrame code not take into account character overshoot? To see what I'm talking about, type something like 'fffffffffffffffffffff' in composer and just hit the backspace key several times, you will notice that the top of the 'f' remains on screen.
I'm pretty booked up right now. Here's some info that might help: 1. text in a frame must be entirely contained within the frame. If it is not, then the text measurement code might be lying about the width of a character. The bug would be in the font metrics stuff and/or text measurement code. Eric v. d. Pool owns this code. 2. I see this on WinNT as well, so marking Platform ALL (was Mac). 3. If you use the editor test mode in viewer and turn on visual debugging, you can see that lower case f is the *only* character that extends beyond the text frame. This makes me suspect the font metrics code even more strongly. I think Erik is on vacation. Frank, who can help Kin track this one down? If no one is available, I'd "future" it.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
PDT downloading to [nsbeta3-].
Whiteboard: [nsbeta3+][p:4] → [nsbeta3-][p:4][minus]
setting to future and adding helpwanted
Keywords: helpwanted
Target Milestone: M18 → Future
*** Bug 70293 has been marked as a duplicate of this bug. ***
*** Bug 49182 has been marked as a duplicate of this bug. ***
I can't reproduce this on 2001110703 (W2KP), or 2001092103 (W95). It also has not been DUPEd in ages. Fixed maybe?
removing myself from the cc list
Looks fixed to me.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.