*Contact emails* [email protected]
*Specification* https://w3c.github.io/mediacapture-screen-share/#dom-mediatrackconstraintset-cursor *ChromeStatus* https://chromestatus.com/feature/5090039641014272 *Summary* Prototype the standardized `cursor` constrainable property for video tracks returned by `getDisplayMedia()`. The property lets an application express whether cursor pixels should be included in the captured display surface. The standardized values are `never`, `always`, and `motion`. The effective value is observable through `getSettings()`, while `getCapabilities()` reports the values supported for the selected display surface. Constraints continue to be applied only after the user chooses a surface. This feature does not filter or restrict the choices in the display-capture picker. *Motivation* Screen-recording and screen-sharing applications need control over whether the mouse cursor appears in the captured output. Some recordings need to omit it, interactive demonstrations need to show it, and motion-only behavior can show the cursor when useful without leaving it permanently embedded in the video. The property is already defined in the W3C Screen Capture specification. Chromium exposes the cursor setting today, but does not expose and honor the complete constraint/capabilities surface consistently across capture backends. *Blink component* Blink>GetDisplayMedia *Initial public proposal* https://github.com/w3c/mediacapture-screen-share/issues/38 The specification change was merged in: https://github.com/w3c/mediacapture-screen-share/pull/58 *Interoperability and compatibility* The API surface and its values are standardized. The main implementation risk is that display-capture backends can support different cursor modes. `getCapabilities()` reports the supported set for the selected surface, and the Chromium implementation remains behind a default-disabled runtime feature while backend support and tests are completed. *Debuggability* Applications can inspect support, supported values, and the effective value through `getSupportedConstraints()`, `getCapabilities()`, and `getSettings()`. Unsatisfied hard requirements use the existing constraint failure behavior. *Testing* The implementation is split into chained CLs covering Blink parsing and selection, Mojo serialization, browser-side preference resolution, native capture backends, FrameSink capture, and end-to-end `getDisplayMedia()` tests. The feature will remain default-disabled until backend integration and validation are complete. *Is this feature supported on all Blink platforms?* No all-platform commitment is made in this I2P. The prototype targets Chromium display-capture paths with backend support, and supported values are exposed per selected surface through `getCapabilities()`. *Tracking bug* https://issues.chromium.org/issues/40649204 -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOJJNu4RDXsWBsgk09oNY55zUYHz4kQBH1yvinsaKaqh-0zKvA%40mail.gmail.com.
