osbytes

Search

Find posts, projects, and members.

← back to blog

Chrome 149 ships today: cross-origin SVG filters die, scrollTo() returns a Promise

2026-06-02by@osbytes5 min read
#browsers #chrome #web-platform #javascript #css #release #breaking-changes

TL;DR

  • Chrome 149 hit Stable today (2026-06-02). The headline behavior change: SVG filter effects no longer apply to cross-origin iframes or plugins. If you filter cross-origin embeds, the filter silently stops.
  • element.scrollTo() (and scroll()/scrollBy()) now return a Promise. Same-origin same-document case unchanged for callers that ignore the return value, but code that chained .then defensively or fed the result somewhere now gets a thenable instead of undefined.
  • BFCache now admits pages with open WebSocket connections (it disconnects them on entry). Pages that previously skipped the back/forward cache because of a live socket can now cache.
  • AccentColor/AccentColorText CSS keywords restricted to installed web apps (anti-fingerprinting). Used them in a normal tab? They stop resolving to the system accent.
  • Also landing: CSS gap decorations, shape()/path() in shape-outside, path-length. Additive, low blast radius.

Cross-origin SVG filters stop applying

This is the one that can change rendering without a console error.

Before 149, an SVG filter (the filter CSS property or a referenced <filter>) on an element could affect a cross-origin iframe or embedded plugin painted underneath it. Chrome 149 closes that: filter effects no longer apply across a cross-origin boundary. It's a rendering-isolation fix, the same family of reasoning that gave us painting and timing restrictions on cross-origin content.

What breaks: if you wrap a cross-origin <iframe> (third-party embed, ad slot, payment widget, an <embed>/<object> plugin) in something that applies a filter — blur, grayscale, drop-shadow, a custom url(#filter) — the filter stops rendering on that subtree in 149. Same-origin iframes are unaffected.

What to check: grep your CSS for filter: near iframe/embed containers, and any backdrop/blur overlays that sit over third-party embeds. If the visual depended on the filter reaching into the embed, it won't in 149. The fix is usually to apply the effect to your own wrapper chrome instead of expecting it to bleed into cross-origin content.

scrollTo() now returns a Promise

Element.scrollTo(), scroll(), and scrollBy() (and the window equivalents) now return a Promise that resolves when the scroll settles, carrying an interruption status so you can tell a completed scroll from one that got cut short.

The common case is fine: most callers fire-and-forget and ignore the return value, and that keeps working. The behavior change bites code that inspected the return value. Previously it was undefined. Now it's a Promise. So:

  • Code asserting el.scrollTo(...) === undefined now fails.
  • Anything that passed the result into a function expecting a non-thenable, or that branched on truthiness, sees different behavior.
  • Polyfills or wrappers that returned their own value and assumed the native call returned nothing may now double up.

What to check: search for scrollTo(, scrollBy(, scroll( where the result is captured into a variable, returned, or compared. The upside is real — you can finally await el.scrollTo({top: 0, behavior: 'smooth'}) instead of guessing with a scrollend listener — but verify nothing downstream choked on getting a thenable.

BFCache admits open WebSockets

Pages with a live WebSocket previously got blocked from the back/forward cache. Chrome 149 lets them in by disconnecting the socket on BFCache entry.

If your app holds a persistent WebSocket (realtime collab, presence, chat, live dashboards), back/forward navigations that used to do a full reload may now restore from BFCache instead. That's faster, but it means your socket is gone on restore and your reload-time setup code didn't run. Listen for pageshow with event.persisted === true and re-open the connection (and resync any state you assumed was live). If you were relying on the socket keeping the page out of BFCache as a de-facto "always fresh" guarantee, that assumption is gone.

AccentColor locked to installed PWAs

The AccentColor and AccentColorText CSS system-color keywords, and accent-color: auto resolving to the system value, are now restricted to installed web app contexts (and the initial profile). In a regular browser tab they no longer expose the user's OS accent color. It's a fingerprinting-surface cut.

If you used AccentColor for theming in a normal tab, it stops resolving to the system accent there. Check form controls and any UI keyed off those keywords, and set an explicit fallback color rather than depending on the system value being available.

The additive stuff

Briefly, because there's no reader action beyond "you can use these now":

  • CSS gap decorations — style the gaps in grid/flex like column-rule does in multicol, with new column-rule-*/row-rule-* properties (including insets and per-item visibility) that animate.
  • shape() and path() in shape-outside — define float-exclusion shapes more flexibly, animatable.
  • path-length — a CSS property mapping to the SVG pathLength attribute, on the usual SVG geometry elements.

No migration needed; they don't change existing behavior.

Sources