[DOGFOOD] Caret placement after last char in doc

VERIFIED FIXED in M12

Status

()

Core
Editor
P1
normal
VERIFIED FIXED
19 years ago
10 months ago

People

(Reporter: buster, Assigned: kinmoz)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] [by 12/10], URL)

(Reporter)

Description

19 years ago
I don't recall the specifics of this problem.  Joe, I think you proposed it, can
you please add some detail?  I think it had to do with trying to get a caret at
the end of a document:  select-all, del, type 1 char, return, problem.
Currently, the infinite loop in insert break problem is keeping me from trying
this.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 1

19 years ago
To reproduce the problem, do this:
1. Select all, delete
2. Type a line, hit return. You get the big caret on the left. Typing makes
   a new line.

I looked at this yesterday, and I think Joe and I will have to come up with
some scheme to keep a bogus text node at the end of the doc in this situation.

Updated

19 years ago
Target Milestone: M10

Updated

19 years ago
Blocks: 12658

Comment 2

19 years ago
M11

Comment 3

18 years ago
This is still a big open issue, for which we have no solution yet.
The problem is that if the selection is at the end of the document, hitting
return enters a <br> at the end of the line, but does not add any white space
(new blank line) to type into, or to put the caret at. This same problem occurs
in table cells too.
(Reporter)

Comment 4

18 years ago
Here's a thought:
Since this is a caret imaging issue, and not a content issue, I assume what we
need is a frame to image the caret into, and not necessarily a piece of
fake content to change selection.
If this assumption is right, then a pseudo-frame might do the trick.  Layout
supports frames that do not map to any content, as well as multiple frames that
map to the same piece of content.  I wonder if we can detect the end-of-document
(and table cell) case and create a pseudo-frame just for the purpose of giving
us the extra line needed to image the caret into. Maybe it's a moz_ style
property?
cc'ing peter, who is wise about such things.

Comment 5

18 years ago
This is not just a caret issue. We need extra vertical space provided by a blank
"line" at the bottom so that the document, or table cell, grows vertically to
provide space to type into.

Comment 6

18 years ago
You could try using a ":after" pseudo element on say the body:
body:after { content: " " }

But since generated content doesn't generally play with selection I'm not sure
it this will do what you want...

Comment 7

18 years ago
*** Bug 14069 has been marked as a duplicate of this bug. ***

Updated

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

Comment 8

18 years ago
Reassigning this, due to current focus on performance issues.

Comment 9

18 years ago
I'm not sure that I'm the right person to own this.  I dont have a clean solution
to this problem from a dom manipulation point of view (which I believe is the
thinking behind passing this bug on to me).  I think we may need to solve this
either with CSS or with some extra smarts in the editor.  I certainly can't do
anything about it M11...

Assigning to buster for further disposition.  Give it back to me if you think I
should have it anyway.  cc'ing simon, Mr Caret.

Updated

18 years ago
Assignee: jfrancis → buster

Updated

18 years ago
Whiteboard: [PDT+]

Comment 10

18 years ago
Putting on [PDT]+ radar.
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 11

18 years ago
sent a note to editor group to get a discussion on this going, will move
discussion to editor newsgroup.
(Reporter)

Comment 12

18 years ago
*** Bug 16888 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Blocks: 16654

Updated

18 years ago
Blocks: 17432

Updated

18 years ago
Priority: P3 → P1
(Reporter)

Updated

18 years ago
Target Milestone: M11 → M12
(Reporter)

Comment 13

18 years ago
was not able to get to this before M11 closed, moving to M12.

Updated

18 years ago
Blocks: 17907

Updated

18 years ago
Blocks: 18471

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] [no firm start/end date yet]

Updated

18 years ago
Blocks: 18951

Updated

18 years ago
Depends on: 19130
(Assignee)

Updated

18 years ago
Assignee: buster → kin
Status: ASSIGNED → NEW
(Assignee)

Comment 14

18 years ago
Assigning to kin@netscape.com
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 15

18 years ago
Accepting bug.

Updated

18 years ago
Whiteboard: [PDT+] [no firm start/end date yet] → [PDT+] [by 12/10]

Comment 16

18 years ago
setting estimated fix date to 12/10, Kin adjust the date to 12/3 if you think
you can get it fixed sooner.
(Assignee)

Updated

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

Comment 17

18 years ago
Woo hoo ... jfrancis@netscape.com (Editor Rules God) checked in a fix for this
over the thanksgiving break.

There are still problems with the caret failing to render when you hit return at
the end of a line (bug #20106) so it might not be so apparent that this bug is
actually fixed. If you click somewhere else in the document and then back on the
blank line, the cursor should reappear.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 18

18 years ago
verified in 11/29 build.

Updated

18 years ago
Blocks: 20870
(Assignee)

Comment 19

18 years ago
*** Bug 19324 has been marked as a duplicate of this bug. ***

Updated

18 years ago
No longer blocks: 17432

Updated

18 years ago
No longer blocks: 17907

Updated

18 years ago
No longer blocks: 18471

Updated

18 years ago
No longer blocks: 18951

Updated

18 years ago
No longer blocks: 20870
You need to log in before you can comment on or make changes to this bug.