Caret disappears at background-color boundary
Categories
(Core :: Web Painting, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: gary_harper, Assigned: emilio)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15
Steps to reproduce:
I am a big fan of FireFox, and have been using it to develop a flowing programming language with box-nested namespaces.
A crucial part is a contenteditable editNode that has a space-tail that must not be encroached upon, tho for structural reasons editing would otherwise permit it. To emphasize its forbidden nature, its background is colored differently than the editing area. I was dismayed to discover that the FireFox caret disappears at that boundary.
This disables my program in FireFox because most editing is done with the caret right at that boundary.
See for yourself: magnify the text in the enclosed test.html file, and walk the cursor from the left up to the 'test' boundary. It will disappear!!!
Safari, Chrome, Edge do not have that problem. Hope you can repair it.
Gary
|
||
Comment 1•5 years ago
|
||
Thanks Gary for the clear report and test case! I can confirm that the cursor disappears at the boundary, but also reappears if you go one character further, and stays present if you then go one character back (i.e., it's now visible at the boundary).
Masayuki, is this something you can look into or should we ask someone from layout?
|
||
Comment 2•5 years ago
|
||
Yeah, I have no idea. If background color is not specified for the inline element, it's not reproducible. Additionally, Selection is correctly set as I expected. So, when moving from outside to inside, Selection range is { container: the preceding text node, offset: the preceding text node length }. I guess that this is layout issue or paint.
|
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 3•5 years ago
|
||
This reproduces all the way back to Firefox 10, at least.
What's happening is that we're painting the caret, but the background paints on top. You can see the issue clearly if you make the background semi-transparent.
So this is a painting order / display list building issue. We could probably either:
- Make
nsCaret::GetCaretFramedetect whether the caret falls in an inline boundary, and "move" the caret to the inline. That probably has other side effects though. - Somehow paint the caret on top of inline backgrounds. Looks like we always paint the caret in the "Content" list, which is what paints with all the other text and such and should paint below the other inline's backgrounds per https://drafts.csswg.org/css2/zindex.html#painting-order.
Matt, do you know off-hand why we put the caret display item in the content list? should we try to change it to the outline list or something else that paints on top of descendant's backgrounds?
For those following along, research on what other browsers do would be ideal to take an informed decision here.
|
|
Assignee | |
Comment 5•5 years ago
|
||
Displaying it in the outlines list seems to work and doesn't cause any badness from a quick local try.
Let's see if it breaks anything, and otherwise I'll write a test and try to get it landed: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6105361bf60e80dbb9627c50aaa169ece976c1c8
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
|
Assignee | |
Comment 7•5 years ago
|
||
I always end up writing some variation of this for local debugging.
|
|
Assignee | |
Comment 8•5 years ago
|
||
There was nothing broken above, so sent a patch along with a test instead :)
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/04e42512e53a Display carets in the outline list, so that descendant backgrounds don't occlude it. r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/caf41ea01dae Add an easier way to skip tests for debugging in tests_reftests_with_caret.html. r=mats
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/04e42512e53a
https://hg.mozilla.org/mozilla-central/rev/caf41ea01dae
Description
•