Contact emailsmc...@chromium.org Explainer https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint
SpecificationNone Note: See here <https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint?tab=readme-ov-file#specification-changes> for intended changes to the html spec. Summary Extends the use of the "opener" rel type to same-window navigations to signal to the browser that the destination page will open a new window and the referring page expects to be able to access it. Some user agents perform browsing context group changes on navigation that aren't strictly necessary for security in order to improve performance. This results in named window reuse not being possible across a back navigation. Annotating an anchor element with "opener" will signal to the user agent that performing a browsing context group change would break a future opener relationship. Blink componentBlink>Internals>Frames <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInternals%3EFrames> TAG reviewNone Note: See here <https://github.com/w3ctag/design-reviews/issues/979> for the early design review. TAG review statusPending Risks Interoperability and Compatibility WebKit wouldn't have to make any changes. They already have the intended behaviour of reusing the existing window, without the use of the proposed annotation, and would be aligned with the spec changes. If Firefox wishes to adopt this behaviour, I wouldn't expect architectural difficulties in doing so. It's a matter of passing a bool through to their isolation logic. Alternatively, it would be fine from a spec perspective if they wish to keep the existing behaviour. The use of an opener rel on a link that targets the same window currently has no effect. There are a small number of pages that do this anyway (see use counter [1]). The only negative effect such pages would experience is a potential unintentional loss of bfcache eligibility. Compared to the lack of clarity from creating a new rel type, this seems worth it. For user agents that don't recognize an "opener" window feature, this could change the window selection to a popup instead of a tab. This wouldn't matter for _self navigations. But in any case, a page could explicitly use the feature "popup=0" to avoid this. [1] https://chromestatus.com/metrics/feature/timeline/popularity/4742 *Gecko*: No signal ( https://github.com/mozilla/standards-positions/issues/1059) *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/383) *Web developers*: Positive (https://issues.chromium.org/issues/40281878) The reporter of the motivating bug has indicated that this proposal would enable their use case without bfcache-ineligibility hacks. *Other signals*: Security No concerns expected. This is not introducing a new capability. It's a more targeted opt-out mechanism for behaviour that can already be achieved. Also note that the page can only use this to avoid optional BCG changes that aren't needed for security. Notably, it can't be used to avoid COOP enforcement. 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 Goals for experimentation To verify that this resolves https://crbug.com/40281878 . To test this, run chrome 128 or later with --enable-blink-features=RelOpenerBcgDependencyHint and annotate the affected links as described <https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint?tab=readme-ov-file#proposed-solution> in the explainer. Ongoing technical constraints None Debuggability None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No Note: Work in progress Flag name on chrome://flagsNone Finch feature nameRelOpenerBcgDependencyHint Requires code in //chrome?False Tracking bughttps://issues.chromium.org/333743493 Estimated milestones DevTrial on desktop 128 DevTrial on Android 128 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5182336170983424 Links to previous Intent discussionsIntent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJGJtGt6AVOw-PESnDmtD__jkjB3o2-hEhos%3Dd4ZrzNo5aiwbg%40mail.gmail.com 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJGJtGuaD5Lfh_eefkMypQEWdb8FzJD3P1HnR8krH4jQCDpRxQ%40mail.gmail.com.
