Re: Setting up an origin trial for MSE-in-Workers

[Matthew Wolenetz]

Resending from @chromium.org account.

On Tue, May 4, 2021 at 1:26 PM Matt Wolenetz <wole...@google.com> wrote:

The MSE API has been stable (and spec has been REC) for several years now.

More recently, I have been working on adding ability for the API to be used from a dedicated worker context (spec issue, crbug, intent to implement, explainer) and have landed the work necessary to enable this behind a blink RuntimeEnabled flag "MediaSourceInWorkers", currently experimental, and shared a demo with interested parties and on the spec issue.

At this point, the feature has stabilized enough to warrant wider Origin Trials and more rigorous specification in response to feedback from early users, the trials, and other implementors.

In order to understand how to launch an OT for this, I need to know:

• To have a way to remotely disable MSE-in-Workers (and to be enabled/disabled via OT), does a blink RuntimeEnabled feature provide the necessary, or must there be an additional flag/feature for this?

Since MSE-in-Workers doesn't qualify for the go/ChromeLaunchProcess, my understanding is the next steps will be to ensure UMA counter(s) are in the code (there is one already, it will be good to have others for different portions of the API that could be used in the worker context), send an I2E (including getting a chromestatus entry filed for this), and then request the trial at go/new-origin-trial.

This is my first OT - so I'm also uncertain: at what point do I add the necessary "origin_trial_feature_name" key/value to the MediaSourceInWorkers RuntimeEnabled feature?

Thank you,

Matt

[Matthew Wolenetz]

Pinging here again, as I need to especially understand if the RuntimeEnabled feature is sufficient for this process.

Thank you,

Matt

[Matthew Wolenetz]

I think I was slightly misinterpreting the related portion of the instructions, and that for this feature which, when enabled, adds visibility to an interface, a RuntimeEnabled feature is sufficient. Please correct if I'm mistaken.

Thanks!

Matt

[Matthew Wolenetz]

Update:

Yesterday, I filed the relevant go/new-origin-trial details and landed an OT integration CL (including UMA counting for the feature and adding origin_trial_feature_name for it).

I'm currently awaiting response from OT folks on next steps.

I'll follow-up separately on any of those responses, just wanted to close the loop here.

[Jason Chase]

Hi Matt, 

Sorry we missed your initial email way back.

I've responded to questions inline. Let us know if you have any further.

We'll review the OT request shortly, and follow up internally if there are any outstanding issues.

Thanks,

Jason

On Fri, 10 Sept 2021 at 14:34, Matthew Wolenetz <wole...@chromium.org> wrote:

Update:

Yesterday, I filed the relevant go/new-origin-trial details and landed an OT integration CL (including UMA counting for the feature and adding origin_trial_feature_name for it).

I'm currently awaiting response from OT folks on next steps.

I'll follow-up separately on any of those responses, just wanted to close the loop here.

On Wed, Sep 8, 2021 at 5:35 PM Matthew Wolenetz <wole...@chromium.org> wrote:

I think I was slightly misinterpreting the related portion of the instructions, and that for this feature which, when enabled, adds visibility to an interface, a RuntimeEnabled feature is sufficient. Please correct if I'm mistaken.

Yes, a RuntimeEnabled feature is sufficient, if you just need to control visibility of interfaces in a dedicated worker. Origin trials are supported in dedicated workers (with the exception of third party tokens, as in crbug.com/1083407).

Thanks!

Matt

On Wed, Sep 8, 2021 at 4:30 PM Matthew Wolenetz <wole...@chromium.org> wrote:

Pinging here again, as I need to especially understand if the RuntimeEnabled feature is sufficient for this process.

Thank you,

Matt

On Tuesday, May 4, 2021 at 1:32:53 PM UTC-7 Matthew Wolenetz wrote:

Resending from @chromium.org account.

On Tue, May 4, 2021 at 1:26 PM Matt Wolenetz <wole...@google.com> wrote:

The MSE API has been stable (and spec has been REC) for several years now.

More recently, I have been working on adding ability for the API to be used from a dedicated worker context (spec issue, crbug, intent to implement, explainer) and have landed the work necessary to enable this behind a blink RuntimeEnabled flag "MediaSourceInWorkers", currently experimental, and shared a demo with interested parties and on the spec issue.

At this point, the feature has stabilized enough to warrant wider Origin Trials and more rigorous specification in response to feedback from early users, the trials, and other implementors.

In order to understand how to launch an OT for this, I need to know:

• To have a way to remotely disable MSE-in-Workers (and to be enabled/disabled via OT), does a blink RuntimeEnabled feature provide the necessary, or must there be an additional flag/feature for this?

We can remotely disable the origin trial, which would prevent issued trial tokens from enabling the Blink RuntimeEnabled feature. If you want to disable the feature entirely (i.e. prevent enabling via the Chrome command line), that would require an additional flag. 

Since MSE-in-Workers doesn't qualify for the go/ChromeLaunchProcess, my understanding is the next steps will be to ensure UMA counter(s) are in the code (there is one already, it will be good to have others for different portions of the API that could be used in the worker context), send an I2E (including getting a chromestatus entry filed for this), and then request the trial at go/new-origin-trial.

This is my first OT - so I'm also uncertain: at what point do I add the necessary "origin_trial_feature_name" key/value to the MediaSourceInWorkers RuntimeEnabled feature?

For future reference, you can add the "origin_trial_feature_name" at any time to a RuntimeEnabled feature. It's effectively a no-op until an origin trial is activated on the OT developer console (although it may require some other code changes).

 

Thank you,

Matt

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/CAADho6PksmqRWvyo4WfVyJQJ_sBPyNbZfiTt_h03RSnESARQ4w%40mail.gmail.com.

[Matthew Wolenetz]

Thank you for your responses. Thankfully, they confirm my understanding; though the dedicated worker 3rd-party token constraint is something I didn't know previously. Fortunately, third party OT is not expected to be required for at least the one expected registrant so far.  I look forward to the internal follow-up.

Matt