'X-Frame-Options' will be ignored when present inside a `<meta>` tag (e.g. `<meta http-equiv="X-Frame-Options" contents="DENY">`). It will continue to be supported as an HTTP header.
We currently try to support `X-Frame-Options` inside `<meta>` tags by cancelling the page load when we parse the tag, and navigating to a blank page instead. This is somewhat functional, but not exactly a reliable protection.
In fact, all of our XFO implementation is somewhat unreliable, as it's all implemented in Blink. We're working on migrating it up to the browser process, but that's going to be difficult to do cleanly if we need to support the `<meta>` implementation. We'll either need implementations in both Blink and //content, or we'll need another IPC.
I'd prefer to simply remove the functionality.
# Compatibility Risk
Safari supports it in a similar way to today's Chrome, with similar caveats.
No page that contains this `<meta>` tag would break outright if we removed support, they would instead lose the marginal clickjacking protection that XFO provides in a page that has already loaded. They still have the option of using the header, or using an imperative anti-clickjacking mechanism (`window.top.location = whatever`). This, of course, is exactly what's happening in IE/Edge and Firefox today.
# Usage Metrics
We don't have UseCounter metrics, but internal tools tell me somewhat reliably that ~20k pages on 154 domains contain a meta tag that we would begin ignoring:
is responsible for ~5k of those pages, and won't be affected at all, as they serve the X-Frame-Options header.
is responsible for ~4k of those pages, and won't be affected at all, as they have commented out the tag.
# OWP Launch Tracking Bug
# Entry on the feature dashboard
# Requesting approval to remove too?