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

NEW
Unassigned

Status

()

9 years ago
5 months ago

People

(Reporter: cacyclewp, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Posted file Testcase

Updated

8 years ago
Version: unspecified → 3.6 Branch

Comment 2

8 years ago
Still does it on Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110626 Firefox/7.0a1 ID:20110626030756
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
Version: 3.6 Branch → Trunk

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → bug 579760

Comment 3

8 years ago
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?
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

8 years ago
Posted patch WIPSplinter Review
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?
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #561587 - Flags: feedback?(roc)
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.
(Reporter)

Comment 7

8 years ago
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 9

8 years ago
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"?
(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.
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.
(Reporter)

Comment 12

8 years ago
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

8 years ago
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

8 years ago
What do you think about that, roc?
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?
(Reporter)

Comment 16

8 years ago
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

8 years ago
(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...
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

8 years ago
(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?
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

8 years ago
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.
(Reporter)

Comment 22

8 years ago
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.

Updated

6 years ago
Attachment #561587 - Flags: feedback?(roc)

Updated

6 years ago
Assignee: ehsan → nobody
(Reporter)

Comment 23

5 years ago
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?
(Reporter)

Comment 24

2 years ago
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?
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
You need to log in before you can comment on or make changes to this bug.