Closed
Bug 39469
Opened 25 years ago
Closed 22 years ago
deleting text leaves visual garbage behind
Categories
(Core :: DOM: Editor, defect, P4)
Core
DOM: Editor
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.
Comment 1•25 years ago
|
||
assigning to Kin for debugging
Assignee: beppe → kin
Target Milestone: --- → M17
Comment 3•25 years ago
|
||
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).
Comment 4•24 years ago
|
||
setting to nsbeta3
Keywords: correctness,
nsbeta3
Target Milestone: M17 → M18
Comment 7•24 years ago
|
||
setting priority in status whiteboard
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]
Comment 8•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
PDT downloading to [nsbeta3-].
Whiteboard: [nsbeta3+][p:4] → [nsbeta3-][p:4][minus]
Comment 12•24 years ago
|
||
setting to future and adding helpwanted
Keywords: helpwanted
Target Milestone: M18 → Future
Comment 13•24 years ago
|
||
*** Bug 70293 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 49182 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
I can't reproduce this on 2001110703 (W2KP), or 2001092103 (W95). It also has
not been DUPEd in ages. Fixed maybe?
Comment 16•23 years ago
|
||
removing myself from the cc list
Looks fixed to me.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•