(Reverse) Origin Trial for old Web Components

[Yoichi Osato]

I'm working for deprecating old Web Components features:

(blink-dev@ Intent to Deprecate and Remove thread)

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/h-JwMiPUnuU/sl79aLoLBQAJ

They are Shadow DOM V0 (hereinafter, SDv0), Custom Element V0 (CEv0) and HTML Imports (Imports).

Feature ID:

https://cs.chromium.org/chromium/src/third_party/blink/public/platform/web_feature.mojom

SDv0:  kElementCreateShadowRoot = 456,

CEv0:  kDocumentRegisterElement = 457,

Imports: kHTMLImports = 455,

I want to use Origin Trials for allowing web authors to use deprecated features, aka “reverse origin trials” from M73 for up to 1 year to help them migrate off of the features.

Chromestatus (2018/07):

 Shadow DOM V0: ~1.8%

 Custom Elements V0: ~4.5%

 HTML Imports: ~1.8%

Public usage is still high but I'm contacting big components customers like Youtube and they're gonna complete migration w/o OT. Many of other sites are using Polymer, which should emulate the features in Chrome w/o the features. 

Then actual user will be much lower than the stats.

[Jason Chase]

First, I had suggested that we start a separate thread from the Intent to Deprecate on blink-dev, given the length of that thread. The API owners have LGTM'd the deprecation plan, so I think we have approval to proceed with the "reverse origin trial" approach.

My goal for this thread is to work out the details of using the origin trial infrastructure to support the deprecation of the old Web Components features.

To restate the obvious, we should be clear that this is *not* an origin trial. The goal is to delay the removal of a feature, rather than experiment with a new feature. I see the similarity is in wanting web developers to signup to explicitly opt in for an origin, for a limited time. Naming is hard, but I'd like to use different terminology, to hopefully avoid confusion. For example, "deprecation delay" (better name please!).

Naming aside, here are some details to iron out:

• I think you want web developers to register for each of the three features separately (SDv0, CEv0, Import)? Meaning they could continue to use one of the deprecated features but not the others? This means more signup friction for developers that are using all 3 together. I think we may want more friction than less (to nudge developers to migrate), but wanted to confirm.
• You want to allow web developers to postpone the deprecation/removal for up to 1 year. For origin trials, we require periodic renewal and feedback via survey (i.e. every 6 weeks in a trial that runs for ~18 weeks). For a 1 year deprecation program, is there benefit in requiring developers to renew, or provide feedback during the year? I would imagine not, but raising the question.
• Speaking of feedback, do you see value in collecting data from developers as to why they need to delay the deprecation on signup? For example, to identify other frameworks dependent on the feature, or issues/bugs in the new v1 features?
• You've indicated that current usage is higher that usual limits for deprecation. Such usage would likely be higher than limits currently applied to origin trials. At a minimum, I think we should consider safeguards that usage doesn't increase under the deprecation program, if not the same limits as currently applied to origin trials.

Given this is a new use for the origin trials infrastructure, I think we should be careful about the precedent we set. We should make decisions to serve the needs of the deprecation for the Web Components features. Ideally, the approach here should be something we'd be comfortable repeating for other deprecated features in the future.

Comments welcome from interested parties, not just yoichio@.

Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "experimentation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to experimentation...@chromium.org.
To post to this group, send email to experimen...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/CAAEV3pksKTfEh_d2xvz4xw%3Dkjum2LOtZtJ7HY-RXtbTAhM8y%2Bw%40mail.gmail.com.

[Yoichi Osato]

Jason, thank you for clearing the situation. 

> Naming is hard, but I'd like to use different terminology, to hopefully avoid confusion. For example, "deprecation delay" (better name please!).

Yes, naming is important so that web authors grasp the concept. How about "feature prolonging" ? "deprecation" is the term saying not to use a feature and we're already deprecating v0s.

> I think you want web developers to register for each of the three features separately (SDv0, CEv0, Import)?

I think one token to use all of them is enough. 

> For a 1 year deprecation program, is there benefit in requiring developers to renew, or provide feedback during the year?  I would imagine not.

I don't think we need feedback because this is not trial.  I think asking developers to renew tokens every 6 weeks can motivate them to migrate.

> Do you see value in collecting data from developers as to why they need to delay the deprecation on signup? For example, to identify other frameworks dependent on the feature, or issues/bugs in the new v1 features?

Yes, developers voice is really welcome. 

>  we should consider safeguards that usage doesn't increase under the deprecation program, if not the same limits as currently applied to origin trials.

According to Origin Trials Guide, we have 0.5% of safeguards, right? I don't understand how this guard really works. Currently CEv0 is used 4.5% in wild and 

youtube is one of the biggest customer. They're working hard to finish their migration work within 2019 Q1 but it is plan and will need this ROT. What if youtube.com consumes 2.0% of pageload ? (FYI, I have been investigating composition ratio of 4.5% but it is unclear so far.)

I'm also new for OT, any good technical document for chrome developer?

I'm planning to remove features only externally. Devtool and Chrome WebUI is using v0.

I'm writing an article on WebFundamentals about deprecation. Could you review/write ROT part?

2018年11月28日(水) 14:37 Jason Chase <cha...@chromium.org>:

[Jason Chase]

Hi Yoichi,

I'm resurrecting this old thread, now that we've turned off WebComponents V0 in 74. The origin trial is configured and ready to be activated, pending some final details.

The outstanding questions:

1) When do activate the trial for sign ups?

2) How often should developers be required to renew tokens?

3) When, if at all, should developers be required to provide feedback on why they need to delay the removal?

For (1), I propose we activate the trial as soon as possible. There seems to be developers that would like to be able to test against Canary/Dev that their sites will work as expected.

Questions (2) and (3) are tied together, as the OT system currently collects/requires feedback only at token renewal time. We've tentatively planned a feature to collect feedback at signup time, but haven't prioritized that yet.

As suggested earlier, I like the idea of requiring token renewal as motivating friction to migrate off of V0. However, I think the standard 6 week period will be too frequent, based on experience with past origin trials. Especially when you consider that some developers will be dependent on larger scale upgrades to their UI framework of choice. I suggest a 3 month renewal period might be a good trade-off between friction and allowing time to upgrade. The result would be:

- Developers sign up nowish for the trial to continue using the features, but aren't required to provide feedback.

- (Optional) If initial feedback is desired, we could send an email to all registered developers. We wouldn't really be able to require responses though.

- In 3 months (~June), tokens expire and developers must provide feedback to renew. We can setup the survey to ask questions about the blockers to migration.

- Repeat every three months, meaning up to 3 renewals before the trial ends in Chrome 80, ~March 2020.

- Permanent removal of the features in Chrome 81 (in stable ~March 2020).

Does that seem like a reasonable approach?

Thanks,

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation-dev+unsub...@chromium.org.
To post to this group, send email to experimentation-dev@chromium.org.

[Yoichi Osato]

The 3-month-renewal token strategy sounds pretty good to me. Go ahead.

BTW, one question for that: can we have actual token usage metrics daily/weekly? I'm afraid updating the usage metrics per 3 month is bit sparse to know a migration trend.

2019年3月2日(土) 0:51 Jason Chase <cha...@chromium.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation...@chromium.org.
To post to this group, send email to experimen...@chromium.org.

[Jason Chase]

OK, I've setup the trial to have tokens last for 90 days.

Internal to Google, we can provide metrics on token registrations and renewals. For privacy reasons, there are limits on what we can share publicly. We would not be able to per-token or per-origin usage.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/CAAEV3pkzHPi%2BUrF4FrLonhUqzEC7U0aADUgWOBtijAUcWCiy7g%40mail.gmail.com.

[Yoichi Osato]

Hi, O.T team.

Could you take a look at the issue of  blink::OriginTrialContext? 

https://bugs.chromium.org/p/chromium/issues/detail?id=939465  

This is blocker of v0 removal.

FYI, I'm leaving this project and Chris is in charge. Regards.

2019年3月5日(火) 1:47 Jason Chase <cha...@chromium.org>:

[Jason Chase]

Yes, I had started investigating the bug, but neglected to update the status to Started.

Thanks,

Jason

[Chris Harrelson]

Hi,

It does seem that issue 939465 blocks the entire reverse origin trial, because otherwise nested documents won't have an opt-in. Is that straightfoward to fix?

After that is fixed, I would like to get any sites which need the reverse origin trial up and running with the trial as soon as possible, even before any flag flip to turn off the v0 APIs again on trunk. We also need a code change in Blink to count reverse-origin-trialed use of the v0 APIs separately from otherwise. This will allow us to measure how much remaining usage there is, and drive that usage down below an acceptable deprecation threshold.

I assume such a metrics measurement has not been done before, but should be straightforward to write in the Blink C++ code. I filed crbug.com/946876 to track this.

Chris

[Jason Chase]

For crbug.com/939465, it should be straightforward to fix. I think I've narrowed down the root cause, and have a workable idea for a fix. I'm continuing to work on that today.

Thanks,

Jason

[mason...@chromium.org]

I would like to resurrect this thread and request an extension of the already-approved Web Components v0 removal origin trial. The original feature removal milestone was M73, and the original origin trial expiration milestone was M80. However, due to excessive feature usage, the removal has been extended to M80. I would therefore like to extend the origin trial to M87.

Is this the right place to request this? Or would you prefer a completely new thread for this extension?

Thanks,

Mason