VerifyCodeDialog OTP input text invisible in light theme (regression from #28623)

[BonsaiSos]

Found a bug? Please fill out the sections below. 👍

Issue Summary

#28623 fixed dark-mode OTP input visibility by adding
text-emphasis caret-emphasis [-webkit-text-fill-color:currentColor]
to digitClassName in VerifyCodeDialog.

In the light theme (embed, theme: "light"), the typed digit is now white-on-white and invisible.

Steps to Reproduce

1. Embed Cal with config={{ theme: "light" }} on an event type
   that requires email verification
2. Select a slot, fill out form, submit
3. Verify-email modal appears; type a digit
4. Digit is invisible

Actual Results

Expected Results

• Verification code fonts should be dark and readable on light theme.

Technical details

• Chrome (147.0.7727.56)

[rahilansari261]

i tried to reproduce it and its fine see the image
and let me know if i am missing something here.

[SahilArate]

Hi,
I have tried to reproduce the error but there is all good the digits are well appear.

[manikanta9090]

Hi, I tried reproducing this but couldn’t see the issue.
Could you provide more details like (browser, screenshots, steps)

[adnan9760]

Hiiiiii @BonsaiSos , I tried to reproducing this but couldn’t see the issue.

[ApurvChoudhary18]

I tried reproducing the issue but i can't see it. Can you share a video of the same ?

[Kaushikgtm]

Took a look at this and I think I understand why the bug is hard to reproduce — sharing in case it helps others on this thread.

The repro needs the embed JS API in a parent page, not just the /embed URL directly. When config: { theme: "light" } is passed to Cal(), the booker iframe is forced into light mode but the parent page's color-scheme still leaks into the iframe's UA defaults. If the parent inherits color-scheme: dark (e.g. from the host's stylesheet or prefers-color-scheme: dark), the element's UA-default -webkit-text-fill-color is white. The CSS added in #28623 — [-webkit-text-fill-color:currentColor] — doesn't override that under those conditions because currentColor resolves against the same affected context.

That's why visiting http://localhost:3000///embed?theme=light directly renders fine for everyone — the iframe isn't wrapped by a parent page with a competing color-scheme.

I've opened a fix at #28985 that binds -webkit-text-fill-color to var(--cal-text-emphasis) directly instead of currentColor. That makes the fill color theme-symmetric by construction and decoupled from any ambient color-scheme. Dark-mode fix from #28623 stays intact.

[nikhilgupta58]

Hi @BonsaiSos and team — PR #29401 is ready for review.

Root cause confirmed: [-webkit-text-fill-color:currentColor] resolves to white when the embed's parent page has color-scheme: dark, because currentColor inherits from that ambient context rather than Cal's theme system.

Fix: Replace currentColor with var(--cal-text-emphasis) — a theme-aware CSS variable (hsla(210,30%,4%,1) in light, hsla(0,0%,98%,1) in dark) that's decoupled from the parent's color-scheme. One line in VerifyCodeDialog.tsx.

Test: New verify-code-dialog.e2e.ts using addInitScript to simulate the dark parent scenario and expect(textFill).toBe(color) as the assertion (stronger than the prior PR #28985 which CodeRabbit flagged for a weak assertion).

@romitg2 @hbjORbj @emrysal — would appreciate a quick look when you have a moment!