[bug]: Theme toggler is now broken because of Chrome update

[jimfaster]

Describe the bug

The location of the center of the wipe effect is broken on the first instance. See screenshot.
Firefox doesn't have this problem. It's chrome, and it's very recent. Probably less than a week old.

Affected component/components

Theme toggler

How to reproduce

go here: https://magicui.design/docs/components/animated-theme-toggler

click the button to switch themes. The first wipe is now broken. the subsequent ones are fine. You need to refresh the page to get that broken one each time.

Codesandbox/StackBlitz link

No response

Logs

System Info

chrome

Before submitting

• I've made research efforts and searched the documentation
• I've searched for existing issues

[Yeom-JinHo]

Hi @jimfaster, thanks for the report! I can't reproduce this on macOS Chrome 150 — it looks like a display-scale related bug in Chrome's first view transition, likely Windows-specific.

Could you share:

1. Exact Chrome version (chrome://version)
2. OS + display scale (e.g. 125% / 150%)
3. Does it still happen at 100% browser zoom (Ctrl+0) and 100% display scale?

Thanks!

[jimfaster]

Disclaimer, I generated this answer with AI. I fixed the problem on my own website, which is using your theme toggle component.

---

Here is my exact environment:

• Windows 11 Home 25H2, 64-bit
• OS build: 26200.8875
• Chrome: 150.0.7871.128
• Windows display scaling: 150%
• Chrome page zoom: 100%
• window.devicePixelRatio: 1.5

Yes, the problem occurred at 100% browser zoom. There was no custom Chrome zoom configured for localhost or the production website.

The coordinates returned by getBoundingClientRect() were correct. In my reproduction, the expected center was approximately (1695, 110), but Chrome rendered the circle near (1130, 73). Both coordinates were effectively divided by 1.5, matching the Windows display scale factor.

Firefox rendered the transition correctly. Older versions of my site also reproduced the problem in the current Chrome version, so it does not appear to be a recent application regression. It matches Chromium issue 535696703.

We fixed it without browser detection, devicePixelRatio compensation, disabling View Transitions, or changing the button measurement. The fix was to express the entire clip-path: circle() geometry as percentages of the viewport-sized reference box instead of absolute pixel values:

const rect = trigger.getBoundingClientRect();
const x = rect.left + rect.width / 2;
const y = rect.top + rect.height / 2;

const viewportWidth = window.innerWidth;
const viewportHeight = window.innerHeight;

const maxRadius = Math.hypot(
  Math.max(x, viewportWidth - x),
  Math.max(y, viewportHeight - y),
);

const xPercent = (x / viewportWidth) * 100;
const yPercent = (y / viewportHeight) * 100;

// Percentage circle radii resolve against the CSS Shapes
// normalized diagonal, not directly against width or height.
const radiusReferenceLength =
  Math.hypot(viewportWidth, viewportHeight) / Math.SQRT2;

const radiusPercent =
  (maxRadius / radiusReferenceLength) * 100;

We then animate:

from {
  clip-path: circle(0% at var(--circle-x) var(--circle-y));
}

to {
  clip-path: circle(
    var(--circle-radius) at
    var(--circle-x)
    var(--circle-y)
  );
}

With:

root.style.setProperty("--circle-x", `${xPercent}%`);
root.style.setProperty("--circle-y", `${yPercent}%`);
root.style.setProperty("--circle-radius", `${radiusPercent}%`);

This fixed the first transition as well as subsequent transitions in Chrome 150 at 150% Windows scaling. It remains standards-compliant and continues to work in Firefox because it does not intentionally alter the CSS coordinates with a DPR multiplier.

This is a standards-compliant workaround for the Chrome regression. The underlying absolute-pixel View Transition bug still belongs to Chromium.

[Yeom-JinHo]

The fix landed in #990 and is now live on https://magicui.design/docs/components/animated-theme-toggler.

@jimfaster could you confirm the first wipe now starts from the button on your setup (Windows 150% scale, Chrome 150)?

[jimfaster]

Yeah it's fixed.
All good.

[Yeom-JinHo]

@jimfaster Great, thanks for confirming and for the excellent report 🙏