1663475 - CSS clip-path clips keyboard caret on Gecko but not on Blink/WebKit

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: clip-path-caret.html

1. Open the attachment
2. See the caret is clipped by clip-path. (It becomes smaller or even invisible inside "bar".)

This currently affects Twitter where emojis use clip-path: circle(0% at center center); which causes carets completely invisible. No such effect on WebKit/Blink.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: emoji-twitter-caret.webm

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Emilio, do you mind taking a look? Thanks!

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Attachment: A test-case with a few other cases.

So our behavior here seems pretty reasonable, off-hand. We treat the caret as a normal item in the flow.

Seems like other browsers paint the caret to the containing block. That sounds a bit sketchy because it may not account for transforms and other things in inlines... But maybe it's fine.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1663475 - Paint caret geometry from the containing block. r=mats

This matches other browsers and shouldn't be too terrible, though I'm
not a terrible fan of it.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

The patch above needs tests and a try run but seems to work. Btw, I just looked this up afterwards, but this is the relevant Chromium code I think... https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/editing/caret_display_item_client.cc;l=55-69;drc=36c0310725bd6a03de6c11dae1d4986e7e64bb18

Kagami, do you know how Safari behaves? I think our current behavior is not bad, Chrome's feels a bit odd to me and maybe we should just reach out to Twitter.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

I don't have Safari access but WebKit Windows build behaves same as Blink does. I agree that it's odd though.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Mats, Masauki, you're familiar with the caret stuff, do you have a strong opinion here?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

From point of view of a11y, caret shouldn't be clipped except by the viewport because it's line mouse cursor for users who use caret browsing mode (I don't know how much users use it). On the other hand, caret is representation of a collapsed selection range. Therefore, clipped as same as non-collapsed selection could be consistent behavior in theory. But I don't have strong opinion, just random thoughts.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

From point of view of a11y, caret shouldn't be clipped except by the viewport because it's line mouse cursor for users who use caret browsing mode (I don't know how much users use it).

Well, but if caret is in invisible element, e.g., transparent <textarea>, it could break backward compatibility.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5dd5f0d3a09b
Paint caret geometry from the containing block. r=mats

Comment 11

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ecffe880103c
Backed out changeset 5dd5f0d3a09b for mochitest failure on test_reftests_with_caret.html CLOSED TREE

Comment 12

[Narcis Beleuzu [:NarcisB]]

Backed out for mochitest failure on test_reftests_with_caret.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/ecffe880103c7e279d2909f63fd93739376d70d2
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=317702481&repo=autoland&lineNumber=4656

Comment 15

[Kagami Rosylight [:saschanaz] (they/them)]

Do we have some blockers here or the it's just the test to be updated?

Comment 16

[Emilio Cobos Álvarez (:emilio)]

I don't recall what the test failure was, but no, the patch should be fine, I'll try to re-land it.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ccc6e271d9db
Paint caret geometry from the containing block. r=mats

Comment 18

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/ccc6e271d9db

Comment 19

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this bug on Firefox 89.0(20210527174632) on Win10 64-bits; Confirmed as fixed on Firefox 99.0(20220328190900) and Nightly 100.a1(20220403215202) on Win 10 64-bits, MacOS 10.15 and Linux x86_64(Ubuntu 20.04).