Thanks for the review Camille. Excellent questions! On Wed, Aug 16, 2023 at 8:21 AM Camille Lamy <[email protected]> wrote:
> Hi Khushal, > > I am reviewing this for security as part of the OWP S&P review process. I > had a few questions regarding the API to make sure we're assessing > it correctly. > > 1. Is the render blocking attribute something that only applies to one > particular document, and does not block rendering of other documents (e.g. > child iframes, parent iframes?)? > > The spec is a bit ambiguous about it because it doesn't explain how rendering opportunities (rAFs) between Documents are intertwined. Implementation wise, we definitely don't allow a child iframe (which is render-blocked) to block rendering of the parent Document. A local child Document is also render-blocked if the parent is. The case with OOPIFs is tricky. If the parent hasn't drawn a frame yet, the child will be assumed to be invisible. We don't render embedded frames unless they are visible. The flow is similar to an iframe starting offscreen and eventually coming onscreen. I'm a bit uncertain whether the child will see 1 rAF (and then get throttled) or no rAFs at all. Also note that render-blocking concept shipped in Chrome via this intent <https://groups.google.com/a/chromium.org/g/blink-dev/c/Ydpc6Lfx_7k/m/hbUNmnyqAgAJ>. This intent is not changing the behaviour in how this feature affects embedded frames. It's adding parsing to the category of resources which can block rendering. > > 1. Can the render blocking attribute only be set by the document that > will be render blocked? > > It's the same as accessing any other attribute on the Document object. If script has access to the Document object, it can set/read this attribute. For example, for a same-origin iframe the embedding Document can access the iframe's Document object so it can set this. > Thanks! > Camille > > On Wed, Aug 9, 2023 at 11:08 PM 'Khushal Sagar' via blink-dev < > [email protected]> wrote: > >> Contact [email protected] >> >> Explainer >> https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md >> >> SpecificationNone >> >> Summary >> >> This feature enables authors to block rendering of a Document until the >> critical content has been parsed, ensuring a consistent first paint across >> all browsers. Without this feature, the first paint's state depends on the >> heuristics for parser yielding which can vary across browsers. This is >> particularly important for View Transitions where the parsed DOM state on >> the first frame can drastically change the transition created. >> >> >> Blink componentBlink>ViewTransitions>MPA >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions%3EMPA> >> >> Motivation >> >> The Web is designed with a model for incremental rendering. When a >> Document is loading, the browser can render its intermediate states before >> fetching all the requisite sub-resources, executing all script or >> fetching/parsing the complete Document. While this is great to reduce the >> time for first paint, there is a tradeoff between showing a jarring flash >> of intermediate Document state (which could be unstyled or have more CLS) >> vs blocking rendering on high priority sub-resources within a reasonable >> timeout. The render-blocking concept helps browsers in making this >> tradeoff. It lets authors specify the set of stylesheets and script >> elements which should block rendering. For example, a stylesheet with the >> rules necessary to ensure a stable layout. But authors can’t specify which >> nodes should be added to the DOM before first render. This proposal aims to >> fill this gap. >> >> >> Initial public proposalhttps://github.com/whatwg/html/issues/9332 >> >> TAG reviewNone >> >> TAG review statusPending >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> None >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?No >> >> Flag name on chrome://flagsNone >> >> Finch feature nameNone >> >> Non-finch justificationNone >> >> Requires code in //chrome?False >> >> Estimated milestones >> >> No milestones specified >> >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5113053598711808 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz5Vmm5hycjwbOkEmFh0KidbGQooxGTOMt0qK2AFhu%2BDg%40mail.gmail.com.
