Disable SVG filters on plugins and iFrames

Syntax. The restricted construct is the CSS filter property with a url() reference to an SVG <filter> element — e.g. filter: url(#my-svg-filter) — declared on a selector that matches an <iframe> whose document is cross-origin to the embedder, or that is restricted (a sandboxed frame, including a same-origin frame with a sandbox attribute). Shorthand and longhand forms are equivalent: filter: url(#f) blur(2px) has only its SVG-reference component skipped. CSS filter functions in the same declaration are not restricted.

Inputs. The behavior is keyed on three inputs, evaluated together: (1) the computed filter value of the iframe element — does it contain an SVG reference filter; (2) the origin relationship between the embedding document and the framed document — same-origin frames (including same-origin srcdoc frames) keep their filters, cross-origin frames lose them, and a frame that navigates from a same-origin srcdoc document to a cross-origin document loses the filter on navigation; (3) the frame's restricted status — a sandbox attribute makes even a same-origin frame restricted.

Outputs. Painted output only: the restricted frame renders as if the SVG reference filter were not declared — the WPT references for the cross-origin and sandbox cases render the iframe with no filter effect at all. Any non-SVG-filter ancestor effect is still applied via the fallback algorithm below. Effect on computed style is not defined in any cited source (explicit unknown): the skip is defined at paint time, which implies the declaration remains in the computed value, but this is not directly sourced and runtime verification on an enforcing build is pending.

Errors. None by design: no exception is thrown, no CSS parse error is produced, and the declaration remains valid — the filter is skipped silently at paint time. Neither the ChromeStatus record nor the proposed spec text defines a console message or other developer-facing signal; whether Chrome emits a devtools warning is not recorded in any cited source (explicit unknown — no stable public source).

Context / exposure. Applies in every Blink context that paints iframes: desktop Chrome 150, Android 150, and WebView 150 (“all platforms using blink”). It is a default-on behavioral change with no flag, no origin trial, and no permissions or capability detection surface; pages cannot opt a restricted frame back into SVG filtering.

Lifecycle / state transitions. The decision is re-evaluated as the frame's state changes, not latched at first paint: the WPT suite covers a same-origin frame that becomes restricted when a sandbox attribute is set and the frame reloads (filter lost after reload), and a srcdoc frame that is navigated cross-origin (filter lost on navigation). Nested frames compose — the suite includes cross-origin-in-cross-origin, cross-origin-in-same-origin, same-origin-in-cross-origin, and same-origin-in-same-origin cases.

Examples.

/* SKIPPED in Chrome 150+ when #frame loads a cross-origin document
   or carries a sandbox attribute — the frame paints unfiltered. */
.restricted-frame {
  filter: url(#svg-filter);
}

/* Still applied: same-origin frame — unchanged behavior. */
.same-origin-frame {
  filter: url(#svg-filter);
}

/* Still applied on ANY frame: CSS filter functions are not
   SVG reference filters. Use these for cross-origin embeds. */
.cross-origin-frame {
  filter: blur(2px) brightness(0.8);
}

<svg width="0" height="0" aria-hidden="true">
  <filter id="svg-filter">
    <feGaussianBlur in="SourceGraphic" stdDeviation="5" />
  </filter>
</svg>

<!-- filtered (same-origin) -->
<iframe class="same-origin-frame" src="/local.html"></iframe>

<!-- unfiltered in Chrome 150+ (sandboxed = restricted) -->
<iframe class="restricted-frame" sandbox src="/local.html"></iframe>

Compatibility.

Security / privacy. This item is the security fix: SVG reference filters let an embedder arbitrarily manipulate the painted pixels of a frame it cannot script-access, enabling clickjacking-style manipulation of cross-origin or restricted content. Dropping the filter removes the embedder's ability to alter how the framed content looks (and thus what the user believes they are interacting with). The restriction trades off a legitimate styling capability on restricted embeds; CSS filter functions remain available as the unaffected alternative.

Syntax. Same restricted construct — filter: url(#svg-filter) — but declared on a selector matching an element that instantiates a web plugin, such as <embed> or <object> (the canonical example being the browser's PDF viewer). The WPT plugin test applies the class carrying the url() filter directly to an <embed type="application/x-webkit-test-webplugin"> element.

Inputs. Two inputs: (1) a computed filter value containing an SVG reference filter, and (2) the element being a plugin-instantiating replaced element. Unlike the iframe case there is no origin input — plugins have no same-origin carve-out in the cited sources; the filter is skipped for plugins unconditionally.

Outputs. Painted output only: the plugin content renders with no SVG filter effect — the WPT web-plugin reference renders the <embed> unfiltered. Computed-style effect is not defined in any cited source (explicit unknown, as with iframes); non-SVG effects around the plugin still apply via the fallback algorithm.

Errors. None by design, as with iframes: the declaration stays valid, no exception is raised, and the skip happens silently at paint time. No cited source defines a console message or devtools signal for the plugin case (explicit unknown — no stable public source).

Context / exposure. Same exposure as the iframe rule — desktop Chrome 150, Android 150, WebView 150, all Blink platforms, default-on with no opt-out surface. The practical case is embedded documents rendered by a plugin (for example PDFs), where the embedder has no access to the plugin's content yet could previously restyle its pixels.

Lifecycle / state transitions. Evaluated at paint time whenever the plugin's element would be painted with an SVG filter effect; there is no latched state. The cited sources define no transitions specific to plugins beyond the shared effect-tree traversal — the WPT coverage is a single static render test with an unfiltered reference.

Examples.

/* SKIPPED in Chrome 150+ — plugin content (e.g. the PDF viewer)
   paints without the SVG filter effect. */
.plugin-embed {
  filter: url(#svg-filter);
}

<!-- Unfiltered in Chrome 150+; the SVG reference filter is skipped. -->
<embed class="plugin-embed" src="document.pdf" type="application/pdf"
       width="600" height="400">

<!-- CSS filter functions remain the working alternative: -->
<style>
  .plugin-embed-dim { filter: brightness(0.85); }
</style>

Compatibility.

Security / privacy. Plugin content (a PDF document, for instance) is rendered by the browser on the user's behalf and is not script-accessible to the embedder — but an SVG reference filter previously let the embedder arbitrarily manipulate its painted pixels, the same clickjacking-style manipulation the iframe rule closes. Skipping the filter restores the invariant that the embedder cannot alter how protected content looks.

Syntax. Not a developer-invoked construct — there is no CSS syntax to write or detect. The algorithm is the browser's defined reaction when a restricted frame or plugin would be painted inside an effect chain that includes an SVG filter: “the effect tree is traversed to find the highest ancestor without SVG filters, and that effect is then applied instead.” A page influences the outcome only by where it places non-SVG effects (e.g. opacity, transform, CSS filter functions) in the ancestor chain.

Inputs. The effect tree of the composited page at the point a restricted frame or plugin is painted, and the set of effects on the path from that frame toward the root — specifically which of those effects involve SVG filters and which do not.

Outputs. The highest ancestor effect that does not include an SVG filter is applied to the restricted content instead of the full effect chain. When no such ancestor effect exists, the practical output is the unfiltered frame — exactly what the WPT restricted-case references render (an iframe or plugin with no filter effect).

Errors. None: the traversal is an internal paint-time fallback with no exception, no invalid declaration, and no defined developer-facing signal in the cited sources (explicit unknown whether any devtools indication exists — no stable public source).

Context / exposure. Runs wherever Blink paints a restricted frame or plugin inside an effect chain — all Blink platforms from Chrome 150. It is not observable from script except through painted output; there is no API, event, or CSS condition that exposes which fallback effect was chosen.

Lifecycle / state transitions. Recomputed as the effect tree changes: restyling ancestors, changing the frame's origin or sandbox state, or navigating the frame all re-evaluate which ancestor effect applies. The WPT reload-as-sandbox and cross-origin-navigation-in-srcdoc tests exist precisely to pin these transitions.

Examples. A non-SVG effect on an ancestor survives and applies to the restricted frame, because it is the highest ancestor effect without SVG filters:

/* The wrapper's opacity is the highest ancestor effect without
   SVG filters — it still applies to the cross-origin frame.
   The SVG filter on the frame itself is skipped. */
.embed-wrapper {
  opacity: 0.9;
  transform: scale(0.98);
}
.embed-wrapper iframe {
  filter: url(#svg-filter); /* skipped for cross-origin/sandboxed frames */
}

Compatibility.

Security / privacy. The fallback preserves the security invariant — the restricted content is never painted through an SVG filter — while keeping the page's remaining visual effects intact, so sites do not lose non-SVG styling (opacity, transforms, CSS filter functions) around legitimate embeds. Reviewers on PR #13846 have asked for the spec to pin down exactly which reference filters and hierarchies are covered so other engines do not have to reverse-engineer this behavior.