We don't have a timeline for removing that restriction. We believe it would be a multi-year engineering project, as it would involve changing the process model for how tabs work in Chromium, and don't have anyone staffed on it. (We filed this tracking bug <https://issues.chromium.org/issues/361129302> for that project though, if you're interested.)
Let us know what sort of data you're looking for in terms of impact. This feature fundamentally is about bringing all the existing impact of prerender, which is pretty well-documented, to the class of sites which use more than one browser tab. On Tue, Jun 3, 2025 at 3:30 AM Barry Pollard <barrypoll...@google.com> wrote: > I've definitely heard back from several companies (large and small) of the > need for this. Erik Witt's analysis may be the only public support we've > got, but there are a number of non-public teams waiting for this too. > > On Mon, 2 Jun 2025 at 19:25, Alex Russell <slightly...@chromium.org> > wrote: > >> Thanks for this. I'm a little concerned that this is a workaround for an >> implementation-based restriction in chromium, and that the goal is to >> remove that restriction through rearchitecture at some point in the near >> future. Do we have a timeline for that? >> >> It would also be helpful to understand the need more clearly. The data >> from Erik Witt was helpful in the sense that it showed the feature works as >> intended, but I wasn't able to understand the overall impact, as there >> wasn't a way to judge those auxiliary context opens as a fraction of >> traffic. Was there more conclusive evidence of the need from other partners? >> >> Best, >> >> Alex >> On Wednesday, May 28, 2025 at 5:57:25 PM UTC-7 Domenic Denicola wrote: >> >>> On Thu, May 29, 2025 at 12:33 AM Alex Russell <slightly...@chromium.org> >>> wrote: >>> >>>> The justification for this feature in the Explainer seems a bit thin. >>>> What's the core problem that requires us to make developers repeat >>>> themselves like this rather than, e.g., deriving the target information >>>> from attributes on <a> elements? >>>> >>> >>> For <a> elements and speculation rules that select them, this >>> information is automatically derived. The use case here is for when URLs >>> are listed explicitly, using the `"urls": [a, b, c]` syntax. Such >>> speculations are most important for pages that reach the given URLs via >>> JavaScript, or via redirects, or other means such that the URL is not >>> directly inside a `href=""`. >>> >>> I agree that the example which the explainer leads with does not make >>> this clear. We'll do a pass to rewrite and clarify the main use case. >>> >>> >>>> >>>> On Wednesday, May 28, 2025 at 8:26:10 AM UTC-7 Chris Harrelson wrote: >>>> >>>>> LGTM2 >>>>> >>>>> On Tue, May 27, 2025 at 7:52 AM Mike Taylor <miketa...@chromium.org> >>>>> wrote: >>>>> >>>>>> Thanks, LGTM1. >>>>>> On 5/23/25 2:15 AM, Domenic Denicola wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wednesday, May 21, 2025 at 10:31:06 PM UTC+9 Mike Taylor wrote: >>>>>> >>>>>> On 5/20/25 6:06 AM, Chromestatus wrote: >>>>>> >>>>>> Contact emails robert...@chromium.org >>>>>> >>>>>> Explainer https://github.com/WICG/nav-speculation/blob/main/ >>>>>> triggers.md#window-name-targeting-hints >>>>>> >>>>>> Specification https://wicg.github.io/nav- >>>>>> speculation/speculation-rules.html >>>>>> >>>>>> Summary >>>>>> >>>>>> This extends speculation rules syntax to allow developers to specify >>>>>> the target_hint field. This field provides a hint to indicate a target >>>>>> navigable where a prerendered page will eventually be activated. For >>>>>> example, when _blank is specified as a hint, a prerendered page can be >>>>>> activated for a navigable opened by window.open(). The field has no >>>>>> effect >>>>>> on prefetching. The specification allows this field to accept any strings >>>>>> that are valid as navigable target name or keyword as the value, but this >>>>>> launch supports only one of "_self" or "_blank" strings. If the hint is >>>>>> not >>>>>> specified, it's treated like "_self" is specified. >>>>>> >>>>>> >>>>>> Blink component Internals>Preload>Prerender >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3EPreload%3EPrerender%22> >>>>>> >>>>>> Search tags speculationrules <http:///features#tags:speculationrules>, >>>>>> prerendering <http:///features#tags:prerendering> >>>>>> >>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/931 >>>>>> >>>>>> TAG review status Issues addressed >>>>>> >>>>>> Origin Trial Name SpeculationRulesTargetHint >>>>>> >>>>>> Chromium Trial Name SpeculationRulesTargetHint >>>>>> >>>>>> Origin Trial documentation link https://github.com/WICG/nav- >>>>>> speculation/blob/main/triggers.md#window-name-targeting-hints >>>>>> >>>>>> WebFeature UseCounter name kSpeculationRulesTargetHintBlank >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> This feature is a small addition to the existing speculation rules >>>>>> feature. Speculation rules itself is a progressive enhancement, so the >>>>>> interoperability risks are low. Additionally, the compatibility risks for >>>>>> this feature are low: if we removed it in the future, it would cause some >>>>>> prerenders to start failing, but prerendering is never guaranteed to work >>>>>> and is hard to depend on. >>>>>> >>>>>> >>>>>> *Gecko*: Neutral (https://github.com/mozilla/ >>>>>> standards-positions/issues/620) Mozilla was notified about this >>>>>> addition to the speculation rules syntax on the overall speculation rules >>>>>> standards positions thread, and gave an overall neutral response to the >>>>>> feature. >>>>>> >>>>>> *WebKit*: No signal (https://github.com/WebKit/ >>>>>> standards-positions/issues/54) >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: SpeedKit/Baqend https://github.com/WICG/nav- >>>>>> speculation/issues/374 We also know of a Google site which has >>>>>> experimented with this feature and successfully used it to enable >>>>>> prerendering which was previously not possible >>>>>> >>>>>> 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 >>>>>> >>>>>> DevTools supports speculation rules: https://developer.chrome.com/ >>>>>> blog/debugging-speculation-rules/ >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? No >>>>>> >>>>>> Android WebView doesn't support speculation rules prerender yet. >>>>>> >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? Yes >>>>>> >>>>>> https://wpt.fyi/results/speculation-rules/prerender >>>>>> >>>>>> I see that many (most?) of the target_hint tests are failing in the >>>>>> latest Canary. Is that expected? >>>>>> >>>>>> >>>>>> We've been struggling with this for some time. You'll notice that >>>>>> this is a general problem with all prerender tests, not specific to the >>>>>> new >>>>>> target_hint feature. >>>>>> >>>>>> Ultimately, we believe that something about how these tests are >>>>>> written makes them not play well with the automation used on wpt.fyi. >>>>>> Note >>>>>> that Edge passes many of the tests we fail, and sometimes we pass tests >>>>>> that Edge fails, likely due to different test infrastructure details on >>>>>> Windows (Edge) vs. Linux (Chrome). >>>>>> >>>>>> This is somewhat understandable, as prerender involves hidden >>>>>> navigables which can confuse the test runner, as well as lots of >>>>>> cross-document messages. We have a few projects under way to clean up the >>>>>> testing infrastructure here and hopefully make it more reliable, but >>>>>> they've been slow-burning. They would certainly shoot up in urgency if we >>>>>> saw active interest from other implementers in prerender. (We're seeing >>>>>> some for prefetch right now, so prerender might be soon!) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Flag name on about://flags >>>>>> enable-speculation-rules-prerendering-target-hint >>>>>> >>>>>> >>>>>> Finch feature name Prerender2InNewTab >>>>>> >>>>>> Rollout plan Will ship enabled for all users >>>>>> >>>>>> Requires code in //chrome? False >>>>>> >>>>>> Tracking bug https://issues.chromium.org/issues/40234240 >>>>>> >>>>>> Availability expectation Feature is available on Web Platform in >>>>>> M138. >>>>>> >>>>>> Sample links >>>>>> https://prerender2-specrules.glitch.me >>>>>> >>>>>> Estimated milestones Shipping on desktop 138 Origin trial desktop >>>>>> first 135 Origin trial desktop last 138 Shipping on Android 138 Origin >>>>>> trial Android first 135 Origin trial Android last 138 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> No spec changes are planned. >>>>>> >>>>>> Link to entry on the Chrome Platform Status https://chromestatus.com/ >>>>>> feature/5162540351094784?gate=5144913335549952 >>>>>> >>>>>> Links to previous Intent discussions Intent to Experiment: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink- >>>>>> dev/67c935cc.2b0a0220.325104.02b6.GAE%40google.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 visit https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/682c5413.2b0a0220.146035. >>>>>> 0187.GAE%40google.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/682c5413.2b0a0220.146035.0187.GAE%40google.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 blink-dev+unsubscr...@chromium.org. >>>>>> >>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8833a3d5-5e77-405f-ad9b-dc80a9f8b6e0%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8833a3d5-5e77-405f-ad9b-dc80a9f8b6e0%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "blink-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/a/chromium.org/d/topic/blink-dev/am_noPAIH5k/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> blink-dev+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0fafb6c-764a-48c4-8f3f-cd9dcd5a72fen%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0fafb6c-764a-48c4-8f3f-cd9dcd5a72fen%40chromium.org?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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-Q90xo7XRNq6QgzPs4Pr2ZxNzSbjxaO9yiORHoW6SEtg%40mail.gmail.com.
