Closed
Bug 10683
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] Caret placement after last char in doc
Categories
(Core :: DOM: Editor, defect, P1)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: buster, Assigned: kinmoz)
References
()
Details
(Whiteboard: [PDT+] [by 12/10])
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•25 years ago
|
Status: NEW → ASSIGNED
Comment 1•25 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•25 years ago
|
Target Milestone: M10
Comment 2•25 years ago
|
||
M11
Comment 3•25 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.
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•25 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•25 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...
Updated•25 years ago
|
Assignee: sfraser → jfrancis
Status: ASSIGNED → NEW
Comment 8•25 years ago
|
||
Reassigning this, due to current focus on performance issues.
Comment 9•25 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•25 years ago
|
Assignee: jfrancis → buster
Comment 10•25 years ago
|
||
Putting on [PDT]+ radar.
Reporter | ||
Comment 11•25 years ago
|
||
sent a note to editor group to get a discussion on this going, will move
discussion to editor newsgroup.
Reporter | ||
Comment 12•25 years ago
|
||
*** Bug 16888 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Priority: P3 → P1
Reporter | ||
Comment 13•25 years ago
|
||
was not able to get to this before M11 closed, moving to M12.
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] [no firm start/end date yet]
Assignee | ||
Comment 14•25 years ago
|
||
Assigning to kin@netscape.com
Assignee | ||
Comment 15•25 years ago
|
||
Accepting bug.
Updated•25 years ago
|
Whiteboard: [PDT+] [no firm start/end date yet] → [PDT+] [by 12/10]
Comment 16•25 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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•25 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.
Comment 18•25 years ago
|
||
verified in 11/29 build.
Assignee | ||
Comment 19•25 years ago
|
||
*** Bug 19324 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•