1752906 - Enable WebMIDI

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, task, P1)

Description

[Gabriele Svelto [:gsvelto] (PTO)]

It's time to flip the dom.webmidi.enabled to true so we can make it go all the way up to release before 97 is cut out.

Comment 1

[Gabriele Svelto [:gsvelto] (PTO)]

Attachment: Bug 1752906 - Enable WebMIDI r=bholley

This turns on Web MIDI by default on Windows, macOS and Linux.
Still off on Android where we don't have support yet.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 9261592 [details]
Bug 1752906 - Enable WebMIDI r=bholley

Beta/Release Uplift Approval Request

• User impact if declined: No access to WebMIDI
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: Would require suitable hardware at QA.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Feature flip for DOM API with little use. Add-on gated so not accessible to normal sites.
• String changes made/needed:

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f1df30c0190a
Enabled Web MIDI by default r=bholley

Comment 4

[Sandor Molnar[:smolnar]]

Backed out changeset f1df30c0190a (bug 1752906) for causing multiple failures in MIDI

Backout link: https://hg.mozilla.org/integration/autoland/rev/3a0db2f1a128e81cf592729feaa8a2990bbeea7f

Push with failures

Failute log mochitest

Failute log wpt

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18c11a93ef16
Enable WebMIDI r=bholley

Comment 6

[Atila Butkovits]

Backed out for causing failures at midi-reporting.https.html.

Backout link: https://hg.mozilla.org/integration/autoland/rev/62b76463b129c111b3aa40d537b03028c3dd4cef

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=DIlsCo7VQ-G3sSXYkg13vw.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=18c11a93ef165c18b95a536fbead227b048bce65

Failure log: https://treeherder.mozilla.org/logviewer?job_id=368136609&repo=autoland&lineNumber=4259

Comment 7

[Gabriele Svelto [:gsvelto] (PTO)]

I've looked into the failures and I'm pretty stumped. The failing test was calling requestMIDIAccess() with site permissions disabling MIDI, so it expected an exception and didn't get it. That was to be expected, so I made some changes to make the operation throw the right exception and then re-run the tests... but they still time out. I have double checked in the C++ code that we're throwing the right exception when requestMIDIAccess() is called and I verified that it's been caught by the test... but somehow it still hangs and I have no idea why.

Comment 8

[Gabriele Svelto [:gsvelto] (PTO)]

Alright, thanks to :padenot's help I patched up this stuff to assume that the test times out (because that's what it and other similar tests do right now) and try is green. Re-landing this, fingers crossed.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/465b14796810
Enable WebMIDI r=bholley

Comment 10

[Narcis Beleuzu [:NarcisB]]

Backed out for wpt failures on idlharness.https.window.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/a8e4ca5c4b7b14a44ca0b08c761c3227b84a98d2
Log link: https://treeherder.mozilla.org/logviewer?job_id=368419088&repo=autoland&lineNumber=3605

Comment 11

[Narcis Beleuzu [:NarcisB]]

Please also check:

1. Mochitest failure on test_midi_device_enumeration.html -> https://treeherder.mozilla.org/logviewer?job_id=368414474&repo=autoland&lineNumber=5385

Comment 12

[Gabriele Svelto [:gsvelto] (PTO)]

Alright, I forgot to revert part of the previous patch and I needed to adjust the results (and prefs) of another web platform test. Tried again locally all green, tried again remotely and it's all green... Hopefully I haven't missed something else this time!

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/695cc7585b70
Enable WebMIDI r=bholley

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/695cc7585b70

Comment 15

[Donal Meehan [:dmeehan]]

Looks like this should be added to the Fx99 release notes.
Could you please confirm and provide some wording?

Comment 16

[Gabriele Svelto [:gsvelto] (PTO)]

Comment on attachment 9261592 [details]
Bug 1752906 - Enable WebMIDI r=bholley

Beta/Release Uplift Approval Request

• User impact if declined: Web MIDI is not enabled
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1748643
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): We're turning on Web MIDI for everybody for the first time. We have addressed all crashes that we encountered during testing but we can't be sure that everything is fully stable until it gets tested by a wider range of users. At the same time this change only impacts a very small subset of our users - those who will be actively using Web MIDI - so the overall risk is mitigated by that.
• String changes made/needed: none

Comment 17

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9261592 [details]
Bug 1752906 - Enable WebMIDI r=bholley

After talking with the dev team, we decided to let it ride the 99 train to make sure we have time to identify potential regressions or webcompat issues in 98, thanks.

Comment 18

[Donal Meehan [:dmeehan]]

:gsvelto Could you please provide some wording for the release notes?

Comment 19

[Hamish Willee]

FYI, docs work for this continues to be tracked in https://github.com/mdn/content/issues/12792

1. Can you confirm this is enabled on all platforms except android for FF99?
2. FF99 also adds secure context, which appears to be just a check of existing user permission and/or a user prompt - is that correct?
3. Do you happen to know if this is enabled in chromium too, and if so what release? It looks like this might be what they released in M77 https://chromestatus.com/feature/5138066234671104

Are you guys still planning on providing some words for a release note?

Comment 20

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Hamish Willee from comment #19)

FYI, docs work for this continues to be tracked in https://github.com/mdn/content/issues/12792

1. Can you confirm this is enabled on all platforms except android for FF99?

Yes

2. FF99 also adds secure context, which appears to be just a check of existing user permission and/or a user prompt - is that correct?
3. Do you happen to know if this is enabled in chromium too, and if so what release? It looks like this might be what they released in M77 https://chromestatus.com/feature/5138066234671104

This mentions M43.

Are you guys still planning on providing some words for a release note?

Yes, sorry for the delay here. The wording could be something like:

Firefox now supports the Web MIDI API on Windows, macOS and Linux. Our implementation has some limitations such as lack of device hot-plug detection but should work with most existing web pages. A site-specific add-on is required to enable the API on your web page.

Paul does the above wording sound OK?

Comment 21

[Hamish Willee]

:gvselto: Thanks very much. Unfortunately this release note prompts some more questions. Specifically this is the first time I have heard about "site-specific permission addons" . They also don't appear on MDN as far as I can tell.

Right now all we say is that you require a secure context, and in Navigator.requestMIDIAccess() we say:

This method may prompt the user for access to MIDI devices available to their system, or it may use a previously established preference to grant or deny access. If permission is granted then the Promise resolves and a MIDIAccess object is returned.

As an end user I presumably get a prompt, but as a developer there is nothing to tell me how I get this permission, or even what the gating permission is. Some questions, which I hope you can answer:

1. I didn't use an add-on during my testing - mostly just ran the various test sites around. That seems to indicate that you can do "some stuff" without the permission. Is that correct? If so, what can be granted with the permission vs what do you get without?
2. Is the site permission addon approach something that is FF only, or is it something others do as standard?
3. Do you know what other features are gated on this, and if not, where I might find out? I can only see WebMIDI on the site permission generator "by default" in the form.
4. Why is the form saying WebMIDI but the prompts rever to SysEx? Is SysEx exclusive access, and that is what you're actually requesting permission for?
5. So we need site permission. What other permissions do we need for this? I.e. are we restricted by the https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API or HTTP Permission Policy (Feature Policy)

In summary, I'm trying to work out what a user will see and what a developer needs to set for access to be gained. Right now it looks like the site permission thing is the only restriction to access.

Comment 22

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Hamish Willee from comment #21)

:gvselto: Thanks very much. Unfortunately this release note prompts some more questions. Specifically this is the first time I have heard about "site-specific permission addons" . They also don't appear on MDN as far as I can tell.

I'm redirecting the NI? to :bolley who knows much more about the new framework than I do (I only worked on the API implementation). Here's answers to the questions I can answer myself:

1. I didn't use an add-on during my testing - mostly just ran the various test sites around. That seems to indicate that you can do "some stuff" without the permission. Is that correct? If so, what can be granted with the permission vs what do you get without?

AFAIK you can disable this gating with the dom.webmidi.gated preferences. Additionally the gating didn't land together with the API so for a while the regular permission framework applied.

4. Why is the form saying WebMIDI but the prompts rever to SysEx? Is SysEx exclusive access, and that is what you're actually requesting permission for?

The current implementation doesn't have a way to distinguish between the two permissions yet, so it always uses sysex access.

Comment 23

[Bobby Holley (:bholley)]

(In reply to Hamish Willee from comment #21)

:gvselto: Thanks very much. Unfortunately this release note prompts some more questions. Specifically this is the first time I have heard about "site-specific permission addons" . They also don't appear on MDN as far as I can tell.

Here is some documentation about how it works: https://extensionworkshop.com/documentation/publish/site-permission-add-on/

We'll be publishing a broader blog post about it once the feature is released.

Right now all we say is that you require a secure context, and in Navigator.requestMIDIAccess() we say:

This method may prompt the user for access to MIDI devices available to their system, or it may use a previously established preference to grant or deny access. If permission is granted then the Promise resolves and a MIDIAccess object is returned.

As an end user I presumably get a prompt, but as a developer there is nothing to tell me how I get this permission, or even what the gating permission is. Some questions, which I hope you can answer:

1. I didn't use an add-on during my testing - mostly just ran the various test sites around. That seems to indicate that you can do "some stuff" without the permission. Is that correct? If so, what can be granted with the permission vs what do you get without?

The requestMIDIAccess() call will always reject unless the add-on is installed (localhost is an exception).

2. Is the site permission addon approach something that is FF only, or is it something others do as standard?

Just Firefox for now.

3. Do you know what other features are gated on this, and if not, where I might find out? I can only see WebMIDI on the site permission generator "by default" in the form.

Just WebMIDI for now.

4. Why is the form saying WebMIDI but the prompts rever to SysEx? Is SysEx exclusive access, and that is what you're actually requesting permission for?

The spec defines a less-powerful subset of the API that does not include the sysex capability (controlled by passing true/false as the sysex parameter to requestMIDIAcccess). For now, Firefox requires the same full permissions (via the addon) for either mode.

5. So we need site permission. What other permissions do we need for this? I.e. are we restricted by the https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API or HTTP Permission Policy (Feature Policy)

You need a secure context (https) and the site-specific add-on to enable the API.

Comment 24

[Paul Adenot (:padenot)]

Yes.

Comment 25

[Bobby Holley (:bholley)]

Attachment: Bug 1752906 - Disable WebMIDI on beta 99.

Comment 26

[Bobby Holley (:bholley)]

Comment on attachment 9270088 [details]
Bug 1752906 - Disable WebMIDI on beta 99.

Beta/Release Uplift Approval Request

• User impact if declined: There are a few bugs in our implementation that we'd like to resolve before releasing.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:

Comment 27

[Bobby Holley (:bholley)]

Comment on attachment 9270088 [details]
Bug 1752906 - Disable WebMIDI on beta 99.

(switching the uplift request from beta to release since we're in rc)

Comment 28

[Donal Meehan [:dmeehan]]

Comment on attachment 9270088 [details]
Bug 1752906 - Disable WebMIDI on beta 99.

Approved for release uplift, available on the beta channel with 99.0rc2. Thanks.

Comment 29

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-release/rev/40500bfc70db

Comment 30

[Donal Meehan [:dmeehan]]

Disabled in 99 via backout.
Removing the release note for 99 also

Comment 31

[Pomax]

I missed this bug, but I'd still like to raise some strong concernss about the new add-on based approach (not the idea behind it, but the specific implementation as used for Web MIDI), and would strongly suggest delaying rollout so that its implementation can be improved to the point where it the gating is automatic, and anonymous, and page authors can trust that their code is browser-agnostic.

To list my concerns:

• this new approach forces people to write code that performs browser detection instead of trusting that the browser will either simply not work, or trigger the user flow necessary for a gated feature to get cleared to work. If Chrome et al start following this model, now we're right back to pages that need to cascade for however many browsers with their own extension stores exist
• devs now need logins to a third part service, just for a web api to work, making the addons site suddenly the authority on which content is allowed to be run in Firefox rather than firefox users being the authority on whether to allow specific content to run.
• because user accounts are now strongly tied to page permissions, there is nothing stopping the addons site from tracking how many unique visitors a page that needs webmidi gets. Not only does this gate the functionality, but it's the kind of strong tie-in that, if Google or Facebook or the like did this, there'd be many complaints about how this violates privacy.

I'm entirely in favour of using addons to regulate permissions, but FF needs to automatically generate and install that addon, without involvement from the person who put the page up on the web: this should be purely between the user and their browser. There should not be any need for an account on an addons site, and definitely nothing that lets third party services (even if Mozilla owns that service) to know which URL is owned by a specific human being, and how many unique FF visitors that gets, and (in the future) how many other pages this user has on the web and what their unique visitor counts are based on which web APIs their pages need.

Comment 32

[Bobby Holley (:bholley)]

Comment on attachment 9270088 [details]
Bug 1752906 - Disable WebMIDI on beta 99.

Beta/Release Uplift Approval Request

We're still tinkering with this, going to delay another cycle.

Comment 33

[Dianna Smith [:diannaS]]

Comment on attachment 9270088 [details]
Bug 1752906 - Disable WebMIDI on beta 99.

Approved for 100.0b9

Comment 34

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2a7b557ab155