579763 - Caret ("cursor") disappears in iframe in designmode (rich text editor) if text color is identical to border color

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Cacycle]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)

The caret disappears when moving it from the left to the right just before a span with a border of the same color as the text before it.

(A similar but maybe unrelated bug is described in 579760)



Reproducible: Always

Steps to Reproduce:
See testcase.

Comment 1

[Cacycle]

Attachment: Testcase

Comment 2

[Tim (fmdeveloper)]

Still does it on Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110626 Firefox/7.0a1 ID:20110626030756

Comment 3

[(no longer active)]

This is where the color is coming from: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCaret.cpp#535

roc: is there a sane way to handle the border color in GetCaretColor?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's the border of the next frame, not the caret's frame, that is the problem in this case, AFAICT.

Maybe if the caret is at the end of a text node we should get the caret color from the beginning of the next content instead of the text node (if there is any)?

Comment 5

[(no longer active)]

Attachment: WIP

This patch looks at the next/previous continuation.  But in the case of the attached test case, there is no next continuation.  Should I grab the next frame from the containing line box or something?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Right, you kind of need to traverse the entire frame tree (in visual order!), or something horrible like that.

I wonder if it's worth using display list analysis to choose the caret color. We could have a new display item method nsDisplayItem::IsUniformIn which takes a rect parameter.

What do other browsers do? To be honest I'm not sure if this is worth fixing.

Comment 7

[Cacycle]

This is a big problem for all rich text editors that use background color styling in the text. It is almost impossible to edit and navigate without a visible caret. Do I understand it right that the caret is alternating between being displayed and being transparent/not displayed? Why not simply alternate between two real colors? That would guarantee visibility in at least one blinking phase. E.g. the nearest text and text background color.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That is a very good idea.

Comment 9

[(no longer active)]

WebKit always paints the caret in black.  When it touches the border, it places the caret inside the border, making sure that it's visible.  Opera seems to alternate between a white and black caret, which is what Cacycle describes in comment 7, I think.

I also think that would make sense.  But it requires us not honor the text color any more.  Would that be an acceptable "regression"?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Ehsan Akhgari [:ehsan] from comment #9)
> WebKit always paints the caret in black.  When it touches the border, it
> places the caret inside the border, making sure that it's visible.

It's probably just normalizing the caret position to the start of the following element instead of letting it be at the end of an element.

> I also think that would make sense.  But it requires us not honor the text
> color any more.  Would that be an acceptable "regression"?

I think so.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Actually I'm afraid that drawing the caret in white on a regular white textarea would look bad. Doesn't it make text look a bit broken?

Normalizing the caret position so that whenever possible we're properly inside a node instead of at the end of a node would make this problem mostly go away.

Comment 12

[Cacycle]

I would actually suggest to alternate between text color and text background color as the caret is something very text-like. Maybe falling back to alternating between black or white versus text background color if text and background have (almost) the same color.

Comment 13

[(no longer active)]

Alternating between the text foreground and background color makes sense to me.  The only case where that would fail is when the two colors are the same, in which case the author is really getting what they asked for.  ;-)

Really, the core of the issue is that we paint the caret using the text color in one timer shot, and we clear it (and don't paint anything) in the next timer shot.  Which is why alternating between two colors would fix this issue.

Comment 14

[(no longer active)]

What do you think about that, roc?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It sounds OK except for the concern in comment #11. If you paint a white caret in a textarea parts of the characters are going to seem to disappear. Isn't that going to look broken?

Comment 16

[Cacycle]

I have checked other programs such as Word how they draw their caret: They "invert" the caret pixels, giving rise to a blinking multicolor line. This is probably the better solution for the rare edge cases with complex backgrounds. But I guess it would require to read out the actual pixels at the caret coordinates.

Comment 17

[(no longer active)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #15)
> It sounds OK except for the concern in comment #11. If you paint a white
> caret in a textarea parts of the characters are going to seem to disappear.
> Isn't that going to look broken?

Yeah, I guess it would.

(In reply to Cacycle from comment #16)
> I have checked other programs such as Word how they draw their caret: They
> "invert" the caret pixels, giving rise to a blinking multicolor line. This
> is probably the better solution for the rare edge cases with complex
> backgrounds. But I guess it would require to read out the actual pixels at
> the caret coordinates.

This is going to have the same problem, I think.

roc, how hard is it to see if a rectangle is on a border of some element?  If it can be detected easily, maybe we can just fixup the rectangle of the caret in these cases...

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could add display-list analysis code to nsCaret::Paint, so it can search under the caret to see what's there and possibly change the caret color.

But what about normalizing the caret position like I suggested?

Comment 19

[(no longer active)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #18)
> We could add display-list analysis code to nsCaret::Paint, so it can search
> under the caret to see what's there and possibly change the caret color.
> 
> But what about normalizing the caret position like I suggested?

I thought that's the same thing that I was talking about.  Or are you suggesting something along the lines of comment 5?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No.

Suppose you have
123<span>456</span>
Currently we allow the caret to be positioned at offset 3 in the first textnode. What if, whenever possible, we prevent the caret from being positioned at the end of a textnode, automatically moving it to start of the next content on the line if possible? In this case we would prefer offset 0 in the second text node.

This would fix this particular testcase, and would prevent similar problems in general, I think, because unless it's at the end of the line the caret would tend to be over text.

Maybe Aryeh's spec says something about this.

Comment 21

[(no longer active)]

Oh, I see, normalizing the selection.  Yes, there's going to be a spec for for that at some point, and once there is, we would want to implement that for all sorts of reasons.  Hopefully that could address this issue as well.

Comment 22

[Cacycle]

Please keep in mind that there might be an almost infinite number of background elements, each with text content and styling, positioned below the caret. Any background pattern, including underlying text, images, and background images, could render transparent/colored carets invisible. We must find a robust and general way to keep the caret visible under any circumstance.

Comment 23

[Cacycle]

Still a *major* problem for rich-text editors under FF 29.0.1 (Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0). It is really difficult to edit content without a caret... Any ideas on fixing this?

Comment 24

[Cacycle]

This bug is still present in 52.0.1 (Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0) and is still a big problem. Anybody willing to work on this?

Comment 25

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 26

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 27

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 28

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.