inserting horizontal line makes caret Jumbo size

VERIFIED FIXED in M12

Status

()

Core
Editor
P3
minor
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: Andrew Niese, Assigned: Joe Francis)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Start the editor either thru -edit or with the tasks menu.

before doing anything else, hit the "H Line" button to insert a horizontal line.
Wow, look at the size of that caret!

June 26 build.

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M8

Updated

19 years ago
Assignee: buster → sfraser
Status: ASSIGNED → NEW

Comment 1

19 years ago
assigned to simon.  Consider the case when the selection can't be text, like
when the document contains only HRs and images: what's our plan?

Updated

19 years ago
Assignee: sfraser → cmanske

Comment 2

19 years ago
The insert HR transaction needs to set the selection properly after inserting the
HR.

Comment 3

19 years ago
*** Bug 8773 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M8 → M9

Comment 4

19 years ago
There is no "insert HR transaction". I'm using nsEditor::InsertNode, which
uses the transaction system. Shouldn't it manage the selection properly?

Updated

19 years ago
Assignee: cmanske → sfraser
Status: ASSIGNED → NEW

Comment 5

19 years ago
Simon fixed this problem for most cases, but there's still a problem when the
element inserted is at the end of a paragraph. In that case we stil get the
big caret, probably because there is no "next sibling" of the
newly-inserted element.
Simon: maybe you should search for a textnode previous
to the inserted element if their is no node at the selection anchor=node+offset?
I'll let Simon sort this out.

Comment 6

19 years ago
I believe this is a similar problem to that described in bug 10683.

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M9 → M10

Comment 7

19 years ago
M10

Updated

19 years ago
Target Milestone: M10 → M11

Comment 8

19 years ago
M11

Updated

19 years ago
Assignee: sfraser → jfrancis
Status: ASSIGNED → NEW

Comment 9

19 years ago
I'm not entirely sure that this is a caret issue, since typing in that situation
behaves oddly too (more vertical space suddenly shows up). Behaviour also depends
on what was split to make the <hr>. This seems related to the end-of-doc case.

Since it looks more like a typing issue, I'm giving it to joe. If you disagree,
joe, please bounce it back.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M11 → M12

Comment 10

19 years ago
M12, dude.
(Reporter)

Comment 11

19 years ago
I love it... m9, to m10, to m11, to m12.
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

18 years ago
This bug is mostly fixed.  There are still cases, I think, where you can get the
uber caret.  But they are a lot rarer now and I would prefer to close this bug
and open new ones against specific remaining scenarios that cause trouble.

Note that there is a seperate bug (20106) about the caret disappearing.  That bug
may make it difficult for you to verify this one.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 13

18 years ago
verified in 11/29 build.
You need to log in before you can comment on or make changes to this bug.