This patch creates a blank class for the VideoFrame interface. The files
are generated by running `./mach build-backend && ./mach webidl-example
VideoFrame` with necessary changes to make it buildable.
The VideoFrame interface is the essential interface for W3C WebCodecs
API, used to represent the decoded video data, decoded image, and the
data ready to be encoded.
The implementations are plain blank now. They will be filled out in the
following patches.
Depends on D144771
Differential Revision: https://phabricator.services.mozilla.com/D144772
This patch creates a blank class for the VideoColorSpace interface. The
files are generated by running `./mach build-backend && ./mach
webidl-example VideoColorSpace` with necessary changes to make it
buildable.
The VideoColorSpace is a sub-interface of the VideoFrame interface,
which is the essential building block for W3C WebCodecs API.
The implementations are plain blank now. They will be filled out in the
following patches.
Additionally, this patch creates a `dom.media.webcodecs.enabled` pref
for W3C Webcodecs API. All the WebCodecs APIs will be hidden without
setting it to `true`.
Differential Revision: https://phabricator.services.mozilla.com/D144771
This patch creates a blank class for the VideoFrame interface. The files
are generated by running `./mach build-backend && ./mach webidl-example
VideoFrame` with necessary changes to make it buildable.
The VideoFrame interface is the essential interface for W3C WebCodecs
API, used to represent the decoded video data, decoded image, and the
data ready to be encoded.
The implementations are plain blank now. They will be filled out in the
following patches.
Depends on D144771
Differential Revision: https://phabricator.services.mozilla.com/D144772
This patch creates a blank class for the VideoColorSpace interface. The
files are generated by running `./mach build-backend && ./mach
webidl-example VideoColorSpace` with necessary changes to make it
buildable.
The VideoColorSpace is a sub-interface of the VideoFrame interface,
which is the essential building block for W3C WebCodecs API.
The implementations are plain blank now. They will be filled out in the
following patches.
Additionally, this patch creates a `dom.media.webcodecs.enabled` pref
for W3C Webcodecs API. All the WebCodecs APIs will be hidden without
setting it to `true`.
Differential Revision: https://phabricator.services.mozilla.com/D144771
This is done by adding Navigator::HasMidiSupport that we reference in
the Navigator.webidl `Func` extented attribute for `requestMIDIAccess`.
A test case is added to browser_midi_permission_gated.js to ensure this
works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D157321
Implement the common steps for the next method from
https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object in
a base class, that all async iterable iterator objects inherit from. Natives
that implement an async iterable only need to implement the "getting the
next iteration result" part in their GetNextPromise method. This means they
don't have to create the object according to "CreateIterResultObject"
themselves, but can just create promise and often resolve it with a native
value directly. We've switched to a special JS::Value to signal "end of
iteration", but that's hidden inside the
iterator_utils::ResolvePromiseForFinished helper.
The WebIDL parser now uses the right return type for the generated "next"
method, which means that any exceptions in the binding code itself will
actually be correctly converted to a rejected promise instead of being
rethrown.
This also uses a class for the generated iterable iterator that's not
exposed outside the binding code. No other code should create and/or
wrap these anyway.
Differential Revision: https://phabricator.services.mozilla.com/D156323
Implement the common steps for the next method from
https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object in
a base class, that all async iterable iterator objects inherit from. Natives
that implement an async iterable only need to implement the "getting the
next iteration result" part in their GetNextPromise method. This means they
don't have to create the object according to "CreateIterResultObject"
themselves, but can just create promise and often resolve it with a native
value directly. We've switched to a special JS::Value to signal "end of
iteration", but that's hidden inside the
iterator_utils::ResolvePromiseForFinished helper.
The WebIDL parser now uses the right return type for the generated "next"
method, which means that any exceptions in the binding code itself will
actually be correctly converted to a rejected promise instead of being
rethrown.
This also uses a class for the generated iterable iterator that's not
exposed outside the binding code. No other code should create and/or
wrap these anyway.
Differential Revision: https://phabricator.services.mozilla.com/D156323
- Define types that match the FedCM spec (https://fedidcg.github.io/FedCM/)
- These are not currently given in the spec, so they have to be inferred from the subsections 5.1-5.4
- I also include the GenerateInit annotation to allow deserialization later
Differential Revision: https://phabricator.services.mozilla.com/D155719
This patch creates a do-nothing IdentityCredential that gives errors when it is used.
The IdentityCredential webidl is defined here:
https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface
Accomplished here:
- IdentityCredential class defined, including isupports and cycle-counting macros
- Empty test added to hold the place of a mochitest folder
- webidl of CredentialsContainer updated and IdentityCredential added
- Logic to parse `identity` key from navigator.credentials.get()
- Adding all of this to the build, including membership to the new bugzilla component DOM: Credential Management
Differential Revision: https://phabricator.services.mozilla.com/D153588
I'm looking to implement the FedCM browser API, which hooks into the Credentail Management API.
Just cleaning up a few preference-gates in webidl and adding new preferences to use as gates.
Differential Revision: https://phabricator.services.mozilla.com/D153586
- Define types that match the FedCM spec (https://fedidcg.github.io/FedCM/)
- These are not currently given in the spec, so they have to be inferred from the subsections 5.1-5.4
- I also include the GenerateInit annotation to allow deserialization later
Differential Revision: https://phabricator.services.mozilla.com/D155719
This patch creates a do-nothing IdentityCredential that gives errors when it is used.
The IdentityCredential webidl is defined here:
https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface
Accomplished here:
- IdentityCredential class defined, including isupports and cycle-counting macros
- Empty test added to hold the place of a mochitest folder
- webidl of CredentialsContainer updated and IdentityCredential added
- Logic to parse `identity` key from navigator.credentials.get()
- Adding all of this to the build, including membership to the new bugzilla component DOM: Credential Management
Differential Revision: https://phabricator.services.mozilla.com/D153588
I'm looking to implement the FedCM browser API, which hooks into the Credentail Management API.
Just cleaning up a few preference-gates in webidl and adding new preferences to use as gates.
Differential Revision: https://phabricator.services.mozilla.com/D153586
- Define types that match the FedCM spec (https://fedidcg.github.io/FedCM/)
- These are not currently given in the spec, so they have to be inferred from the subsections 5.1-5.4
- I also include the GenerateInit annotation to allow deserialization later
Differential Revision: https://phabricator.services.mozilla.com/D155719
This patch creates a do-nothing IdentityCredential that gives errors when it is used.
The IdentityCredential webidl is defined here:
https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface
Accomplished here:
- IdentityCredential class defined, including isupports and cycle-counting macros
- Empty test added to hold the place of a mochitest folder
- webidl of CredentialsContainer updated and IdentityCredential added
- Logic to parse `identity` key from navigator.credentials.get()
- Adding all of this to the build, including membership to the new bugzilla component DOM: Credential Management
Differential Revision: https://phabricator.services.mozilla.com/D153588
I'm looking to implement the FedCM browser API, which hooks into the Credentail Management API.
Just cleaning up a few preference-gates in webidl and adding new preferences to use as gates.
Differential Revision: https://phabricator.services.mozilla.com/D153586