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)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: buster, Assigned: kinmoz)

References

(
URL
)

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.
Status: NEW → ASSIGNED
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.
Target Milestone: M10
Blocks: 12658
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.
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.
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...
*** Bug 14069 has been marked as a duplicate of this bug. ***
Assignee: sfraser → jfrancis
Status: ASSIGNED → NEW
Reassigning this, due to current focus on performance issues.
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.
Assignee: jfrancis → buster
Whiteboard: [PDT+]
Putting on [PDT]+ radar.
Status: NEW → ASSIGNED
sent a note to editor group to get a discussion on this going, will move
discussion to editor newsgroup.
*** Bug 16888 has been marked as a duplicate of this bug. ***
Blocks: 16654
Blocks: 17432
Priority: P3 → P1
Target Milestone: M11 → M12
was not able to get to this before M11 closed, moving to M12.
Blocks: 17907
Blocks: 18471
Whiteboard: [PDT+] → [PDT+] [no firm start/end date yet]
Blocks: 18951
Depends on: 19130
Assignee: buster → kin
Status: ASSIGNED → NEW
Assigning to kin@netscape.com
Status: NEW → ASSIGNED
Accepting bug.
Whiteboard: [PDT+] [no firm start/end date yet] → [PDT+] [by 12/10]
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
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.
Status: RESOLVED → VERIFIED
verified in 11/29 build.
Blocks: 20870
*** Bug 19324 has been marked as a duplicate of this bug. ***
No longer blocks: 17432
No longer blocks: 17907
No longer blocks: 18471
No longer blocks: 18951
No longer blocks: 20870
You need to log in before you can comment on or make changes to this bug.