This has been submitted as https://chromiumdash.appspot.com/commit/af269bab5f16b6a8304f1b820bca16c5118943f2 and will roll out in M135. Thanks,
F On Tuesday, February 25, 2025 at 6:54:08 PM UTC+9 Fergal Daly wrote: > I would like to rollout this change in M135 (cutting next week). There has > been no response to Domenic's argument that this is *very unlikely* to > cause breakage. Unless someone argues that this needs to be more than a > PSA, I will proceed, > > Fergal > > On Wednesday, November 13, 2024 at 6:11:08 PM UTC+9 Domenic Denicola wrote: > >> I spent some time discussing this with the team internally before this >> was sent, with the tentative conclusion that a PSA was appropriate instead >> of a full Intent to Ship. >> >> Here are the factors that indicate this to me: >> >> - As Yuzu states, in practice we expect these values to be treated as >> opaque strings, bucketed by reporting APIs. It is extremely hard to >> imagine >> user-visible breakage from any reasonable coding pattern; it would be >> similar to expecting user-visible breakage from changing exception >> message >> strings. (Possible! But not usually considered to require an Intent to >> Ship.) >> >> The shipping guidelines state >> >> <https://www.chromium.org/blink/launching-features/#behavior-changes:~:text=Non%2Duser%2Dvisible%20breakage%20(e.g.%20breakage%20in%20reporting%20or%20monetization)%20is%20still%20considered%20functional%20breakage.> >> reporting >> breakage is still considered as important, so the question is whether we >> believe this change is "very unlikely" >> >> <https://www.chromium.org/blink/launching-features/#behavior-changes:~:text=Use%20%22Web%20developer%20facing%20code%20change%22%20only%20for%20changes%20deemed%20very%20unlikely%20to%20break%20sites%2C%20and%20that%20change%20APIs%20in%20at%20most%20a%20trivial%20way.> >> >> to break such reporting backends. I agree with the team that such >> reporting >> breakage is very unlikely. Site owners might see some failures migrate >> from >> the "unload-listener" to "unload-handler" buckets on their dashboards, >> which could be slightly strange, but it doesn't seem like breakage. >> - Unlike exception messages, bfcache reporting reasons are written >> down in specs. But, this change is aligning with the specification. If in >> the future the team plans to perform more renames or additions of bfcache >> blocking reasons, those will go through the usual spec process, and come >> with a corresponding Intent to Ship. So this is more of a bugfix, and not >> a >> full "new feature". >> - The majority of the changed reasons (4/5) are migrating from >> specific reason strings to "masked", which is the per-spec fallback that >> the browser is always allowed to send. In general web pages and reporting >> software need to be resilient to the contents of the "masked" bucket >> fluctuating between browsers and browser versions. >> - The team flag-guarded this change so if somehow, something breaks, >> it can be remotely rolled back. >> >> >> On Fri, Nov 8, 2024 at 2:32 PM Yuzu Saijo <yu...@chromium.org> wrote: >> >>> +bfcache-...@chromium.org <bfcache-...@chromium.org> >>> >>> On Thu, Nov 7, 2024 at 3:01 PM Yuzu Saijo <yu...@chromium.org> wrote: >>> >>>> Thanks Yoav for the question. >>>> >>>> I realized that we have a usage counter but in a wrong place >>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_navigation_timing.cc;l=429;bpv=1;bpt=1?q=WebFeature::kBackForwardCacheNotRestoredReasons%20-f:out&ss=chromium>, >>>> >>>> and it is now just counting the number of history navigation. >>>> So at the moment we don't know how many people use the API. >>>> I will send out a CL to change this. >>>> >>>> We are thinking of reaching out to RUM users so that they can be aware >>>> of the upcoming change. >>>> But basically this API's report values are like histograms and sites >>>> must handle new values and values that are not present. >>>> >>>> On Tue, Nov 5, 2024 at 4:14 PM Yoav Weiss (@Shopify) < >>>> yoavwe...@chromium.org> wrote: >>>> >>>>> What does current usage look like? Have you reached out to folks who >>>>> may be using the API to notify them that they'd need to adapt their >>>>> backend >>>>> code? >>>>> >>>>> On Tue, Nov 5, 2024 at 5:57 AM Yuzu Saijo <yu...@chromium.org> wrote: >>>>> >>>>>> >>>>>> We are going to change the names reported in NotRestoredReasons API >>>>>> so that they match the specified names. NotRestoredReasons API has been >>>>>> launched for 6 months now. >>>>>> >>>>>> The change is likely to land with a flag in M133. >>>>>> We expect that web developers are counting these values. Since this >>>>>> is an API that reports events about a previous instance of the page, we >>>>>> do >>>>>> not expect that any client-side code takes any action based on >>>>>> specific strings. >>>>>> >>>>>> Server side code which presents reports based on this API's data may >>>>>> attach advice to developers on how to avoid blocking BFCache for certain >>>>>> reasons. This would need to attach the advice to the new values and the >>>>>> old >>>>>> values. Similarly developer-targeted articles may reference the old >>>>>> values. >>>>>> >>>>>> ChromeStatus entry: https://chromestatus.com/feature/6444139556896768 >>>>>> Spec PR: https://github.com/whatwg/html/pull/10154 >>>>>> >>>>>> -- >>>>>> 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/CAPK8OYiAWY-8Hsy0MK3FYLOpTrs87knwWbRhhzby2ZLsgOOWDg%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPK8OYiAWY-8Hsy0MK3FYLOpTrs87knwWbRhhzby2ZLsgOOWDg%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 blink-dev+unsubscr...@chromium.org. >>> >> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPK8OYhFSHUy4FFVdScQS6ix44UuO0moecNNMLxFeR%3D5_iT5qQ%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPK8OYhFSHUy4FFVdScQS6ix44UuO0moecNNMLxFeR%3D5_iT5qQ%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7147fdc6-5529-4b97-9c2d-515931d4704dn%40chromium.org.
