Leverage Document-Policy implementation in Blink

[paulirish]

Mostly brain dumping my research for future us...

The history of "Document Policy" is weird... Feature-Policy (i have a PR to retitle Eric's nice blogpost..) was introduced in 2018. It had features to control access to permissions and then a handful of UX-y checks/controls for common UX problems.

The whole thing was split into Permission Policy and Document Policy. Though weirdly document.featurePolicy.allowedFeatures() still exists and has a listing of the union.

The permission policy stuff got fairly formalized and adopted. But theres this handful of old UX-y checks in Document-Policy that are VERY similar to Lighthouse audits. They may be useful to us as we consider some core refactors..

resources

• https://github.com/w3c/webappsec-permissions-policy/tree/main/policies
• https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/mojom/permissions_policy/document_policy_feature.mojom;l=7-39;drc=09ae39cb337e46a2f97a763e57986154b8af91eb Enum of feature flags, but doesn't necessarily map to Policy directives. xrefs point to impl
• https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/permissions_policy/document_policy_features.json5 list of policy directives
• https://calendar.perfplanet.com/2022/document-policy-and-performance/
• https://timkadlec.com/remembers/2020-02-20-in-browser-performance-linting-with-feature-policies/
• https://feature-policy-demos.appspot.com/ and https://developer.chrome.com/blog/feature-policy/ from Eric
• https://web.dev/articles/image-policies (some retired directive names in here)
• https://featurepolicy.info/ from Andrew Betts

document policy features

• animations: reports layout-causing (non composited) animations
• font-display-late-swap: something about use of font-display: optional.... I think if the font is loading late (and thus optional would help), it notify and maybe overrides? Not sure if it reports use of other values.
• sync-script: Don't do inline scripts or script[src] without defer/async.
• oversized-images: Don't use images that are naturally too big and therefore excessively scaled down into their container. Has a user-configurable "downscale ratio" parameter.
• lossless-images-strict-max-bpp, lossless-images-max-bpp, lossy-images-max-bpp. Like our optimized-images audit, with a customizable byte-per-pixel ratio.
• unsized-media: like our unsized-images audit.
• document-write: Can block usage.
• sync-xhr (in permissions policy, actually): reports when sync xhrs are used
• js-profiling: Enables use of JS self profiling api. very unrelated.
• force-load-at-top. Allows pages to opt out of scrolling on pageload (like to a fragment). Not relevant for us.

I'm not sure that all of these can currently run in report-only mode, but.. it should be possible to add trace events, etc. (related)

[paulirish]

Could we adopt these ?

• animations: AFAIK the implementation for this gave us the trace events that we consume already. Done.
• font-display: The Lighthouse logic gives you a pass if you set swap or optional. (or if you very deliberately say you want to make the user wait with block or fallback.) But the doc policy is going for something slightly different (right?!). That said, the impl looks clear enough for us to add a trace event there. 🖖
• sync script. pretty close to the recently discussed new audit Scripts without document.write() should be either async or defer #15416
• oversized-image: looks just like our uses-responsive-images audit logic. Possibility there to reuse. 👍
• loss*-images-max-bpp: definite possibility to reuse impl for optimized-images. would skip actually re-encoding, but... that's probably ok.. 👍
• unsized-media: definite possibility to reuse impl for our unsized-images. Plus we'd pick up support for video/svg. 👍
• document-write: The violation we consume and this check appear to be in different code paths. weird. But.. presumably we're already good.
• sync-xhr: we could add a trace event & new audit for this, if we want to