Ok. I think this will be quite iterative and we'll try to figure out the exact set of customizations and optimizations during the origin trial, so if we can just request 6 milestones from the start maybe that's ideal (139-144). Thanks!
Regards, Rakina On Fri, Jul 18, 2025, 02:07 Mike Taylor <miketa...@chromium.org> wrote: > Thanks - you can request an OT for up to 6 milestones > <https://www.chromium.org/blink/launching-features/#:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones%20of%20Chromium>, > but you will know better what makes sense for your feature. 3 might make > sense, or more. Please let us know. :) > On 7/16/25 7:07 p.m., Rakina Zata Amni wrote: > > Oh sorry, I didn't realize there's a different field for OT. I'm > requesting OT from 139. Not sure how many versions typically OTs should > last for (3 milestones)? > > On Thu, Jul 17, 2025 at 2:57 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> Could you clarify which milestones you're requesting to experiment on? >> (Right now it just shows DevTrial on 139) >> On 7/16/25 11:31 a.m., Chromestatus wrote: >> >> Contact emails rak...@chromium.org, m...@chromium.org >> >> Explainer https://github.com/explainers-by-googlers/fetch-retry/tree/main >> >> Specification None >> >> Design docs >> >> https://docs.google.com/document/d/1C9lAn3tqXsrjxiid1qCC9qSL7jfA1PZdoo2lgL8L5Pw/edit?tab=t.0 >> >> Summary >> >> Allow web developers to indicate that a fetch() request should be >> retried, to have a greater guarantee on it being reliably sent, even if >> network is flaky. This is especially important for keepalive fetches, where >> the request might outlive the document, which can no longer watch for its >> failure and do manual retry. We intend to only support this for keepalive >> fetches for now because of implementation simplicity, and also the fact >> that all the use cases would benefit from being keepalive first. >> >> >> Blink component Blink>Loader >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELoader%22> >> >> TAG review None >> >> TAG review status Pending >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal (https://github.com/whatwg/fetch/issues/1838) Safari >> devs have responded in the proposal thread and gave constructive feedback >> and doesn't seem to be opposed. >> >> *Web developers*: Positive ( >> https://github.com/whatwg/fetch/issues/1838#issuecomment-3035074583) >> Internal developers interested in origin trial. External developers have >> proposed a similar feature/made libraries similar to this, and generally >> seems interested in the proposal thread. >> >> *Other signals*: >> >> Security >> >> Resource Exhaustion: Malicious or misconfigured sites could attempt to >> trigger excessive retries, potentially impacting network resources or >> target servers. Mitigation relies on browsers enforcing strict, reasonable >> limits on maxAttempts and maxAge, alongside implementing backoff delays. >> Timing Attacks/Information Leakage: The timing patterns of retry attempts >> could theoretically leak some information about network conditions. This is >> unlikely to provide substantially more information than can already be >> inferred by observing standard network request timings and failures. >> Additionally the browser will ensure that the errors are not exposed to the >> script until max age set in the retry options is reached, regardless of >> whether a retry happened or not, and only the latest error is exposed >> instead of all attempts.The risk is considered low. >> >> >> 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 >> >> 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 >> >> This feature is essentially invisible to the script initiating the fetch >> since it can't know if a retry happened or not. >> >> >> Flag name on about://flags >> >> Finch feature name FetchRetry >> >> Requires code in //chrome? False >> >> Tracking bug https://crbug.com/417930271 >> >> Estimated milestones >> DevTrial on desktop 139 >> DevTrial on Android 139 >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5181984581877760?gate=5140384199737344 >> >> Links to previous Intent discussions Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r6QFoqcmdoEMeG4JKJXGLqvGW%2BMr-UZj%2Br6HrQ%3DTNqKYQ%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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6877c5df.170a0220.a2b55.0311.GAE%40google.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6877c5df.170a0220.a2b55.0311.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/CACPC1r54nPFm6-exTjgNcO%2BwKFKsEhKWhaqiq7DiRRz6F_uQXg%40mail.gmail.com.
