Web-Facing Change PSA: NotRestoredReasons name change

[Yuzu Saijo]

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

[Yoav Weiss (@Shopify)]

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?

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPK8OYiAWY-8Hsy0MK3FYLOpTrs87knwWbRhhzby2ZLsgOOWDg%40mail.gmail.com.

[Yuzu Saijo]

Thanks Yoav for the question.

I realized that we have a usage counter but in a wrong place, 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.

[Yuzu Saijo]

+bfcac...@chromium.org 

[Domenic Denicola]

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 reporting breakage is still considered as important, so the question is whether we believe this change is "very unlikely" 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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPK8OYhFSHUy4FFVdScQS6ix44UuO0moecNNMLxFeR%3D5_iT5qQ%40mail.gmail.com.