Closed
Bug 87634
Opened 24 years ago
Closed 13 days ago
Caret becomes equal to height of a paragraph
Categories
(Core :: DOM: Selection, defect, P5)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: apa3a, Unassigned)
Details
(Whiteboard: [caret])
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010620
BuildID: 2001062021
Sometimes caret becomes huge - equal to height of a paragraph.
Reproducible: Always
Steps to Reproduce:
1. Write to yourself an email message of the following contents (3 lines of 'r'
symbol without stars delimiter):
******************************
rrrrrrrrrrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrrrrrrrr
******************************
Be sure you have the mail composer settings as I do (see below).
2. Receive the message.
3. Call reply to it - the compose window should appear.
4. Go to the end go to the end of line on the last 'r' line, press and keep
<Del> key.
Actual Results: The caret becomes big when all the characters to the end of
message are removed.
Expected Results: The caret should remain the same size.
My email composer has configuration to quote the text on reply and put reply
below the quoted message. I compose the message in plain text, not in HTML.
Mesage display: fixed width font, wrap text to window width turned on.
The same issue - big caret was in bug 82101 with different conditions.
Comment 1•24 years ago
|
||
jfrancis
Assignee: beppe → jfrancis
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [caret]
Target Milestone: --- → mozilla1.0
Comment 2•24 years ago
|
||
Not much can be done about this. All the content past the quotation is gone.
Sending over to selection... editor is powerless to prevent all cases of ubercaret.
Assignee: jfrancis → mjudge
Component: Editor → Selection
QA Contact: sujay → tpreston
Target Milestone: mozilla1.0 → Future
Updated•16 years ago
|
Assignee: mjudge → nobody
QA Contact: tpreston → selection
Comment 3•5 years ago
|
||
Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.
If you have reason to believe this is wrong, please write a comment and ni :jstutte.
Severity: minor → S4
Priority: P3 → P5
I don't reproduced this bug. Currently, caret size is considered with the last nsTextFrame
in the case, so, this must have been fixed.
Status: NEW → RESOLVED
Closed: 13 days ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•