10683 - [DOGFOOD] Caret placement after last char in doc

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P1)

Description

[buster]

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.

Comment 1

[Simon Fraser [no longer active]]

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.

Comment 2

[Simon Fraser [no longer active]]

M11

Comment 3

[Simon Fraser [no longer active]]

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.

Comment 4

[buster]

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

[Simon Fraser [no longer active]]

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

[Peter Linss]

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

[Simon Fraser [no longer active]]

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

Comment 8

[Simon Fraser [no longer active]]

Reassigning this, due to current focus on performance issues.

Comment 9

[Joe Francis]

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.

Comment 10

[leger]

Putting on [PDT]+ radar.

Comment 11

[buster]

sent a note to editor group to get a discussion on this going, will move
discussion to editor newsgroup.

Comment 12

[buster]

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

Comment 13

[buster]

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

Comment 14

[kinmoz]

Assigning to [e-mail]

Comment 15

[kinmoz]

Accepting bug.

Comment 16

[rubydoo123]

setting estimated fix date to 12/10, Kin adjust the date to 12/3 if you think
you can get it fixed sooner.

Comment 17

[kinmoz]

Woo hoo ... [e-mail] (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

[sujay]

verified in 11/29 build.

Comment 19

[kinmoz]

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

Comment 20

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/abf1eece889d
[fenix] For https://github.com/mozilla-mobile/fenix/issues/10683: Show longer tab titles