Skip to content

Specification has been updated #14

@KristofferStrube

Description

@KristofferStrube

As shown on the Status page, the spec has been updated. Some things have been added, and some things have changed.

Changed

  • type of echoCancellation on MediaTrackCapabilities to sequence<(boolean or DOMString)> from sequence<boolean>. ⚠️
  • type of echoCancellation on MediaTrackConstraintSet to ConstrainBooleanOrDOMString from ConstrainBoolean. ⚠️
  • type of echoCancellation on MediaTrackSettings to (boolean or DOMString) from boolean. ⚠️
  • the event type of devicechange to DeviceChangeEvent from Event.

Some of these changes (marked with ⚠️) would result in binary-breaking changes as the types in the wrapper would change. So we need a major version for these changes. Currently, the wrapper is broken in Chrome if the camera returns one of the EchoCancellationModeEnum values in its MediaTrackCapabilities, which I have observed recently. So I would like to update it soon. I might even make a major release with these changes alone, before the added features are done, to stabilize it again. Another option is to temporarily make a fix for it by adding a custom converter for a bool[]? that would ignore types that were not a bool.

Added

  • boolean backgroundBlur to MediaTrackSupportedConstraints.
  • sequence<boolean> backgroundBlur to MediaTrackCapabilities.
  • ConstrainBoolean backgroundBlur to MediaTrackConstraintSet.
  • boolean backgroundBlur to MediaTrackSettings.
  • EchoCancellationModeEnum type.
  • DeviceChangeEvent type.
  • DeviceChangeEventInit type.
  • getUserMedia on Navigator, which is our MediaDevicesService.
  • ConstrainBooleanOrDOMStringParameters which has properties that should be a union of a bool and EchoCancellationModeEnum.
  • ConstrainBooleanOrDOMString which should be represented by a union type of bool, EchoCancellationMode, and ConstrainBooleanOrDOMStringParameters.

All of these can be added without issue.

Could I have caught it earlier?

Yes. First, I could have added more tests, but having them alone would not have helped if I did not run them periodically. I'm considering creating a job or similar process to run my tests periodically and alert me if they suddenly fail to parse. That could be expanded further in a subsequent issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions