whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.03k stars 2.63k forks source link

[Proposal] capture screen #10382

Open hemanth opened 3 months ago

hemanth commented 3 months ago

What problem are you trying to solve?

Proposal for window.screenshot API

Use Cases

The primary use case for a window.screenshot API is to enable web applications to capture and manipulate screenshots directly within the browser. Here are specific scenarios where such an API would be beneficial:

  1. Web-based Design Tools

    • Requirement: Capture screenshots of the current viewport or specific elements.
    • Benefit: Allows designers to quickly capture and manipulate design elements without needing external tools.
  2. Bug Reporting

    • Requirement: Users can capture screenshots of errors or bugs directly from the web application.
    • Benefit: Simplifies the bug reporting process by providing visual context, leading to faster resolution.
  3. Educational Tools

    • Requirement: Capture and annotate screenshots for tutorials and guides.
    • Benefit: Facilitates the creation of educational content by enabling direct screenshot capture and annotation within the web application.

Requirements

To meet these use cases, the window.screenshot API must provide the following capabilities:

Comparison with Existing APIs

Currently, there is no direct equivalent to a window.screenshot API in the existing web platform. While the Canvas API can be used to capture and manipulate images, it requires complex and verbose code. The proposed window.screenshot API would simplify this process significantly, making it more accessible to developers.

Conclusion

The window.screenshot API addresses a clear need for capturing and manipulating screenshots within web applications. By focusing on essential requirements and learning from past experiences with storage APIs, we can introduce a robust and secure API that enhances the web platform's capabilities. This proposal aims to gather feedback and iterate towards a solution that meets developer needs while ensuring user security and performance efficiency.

What solutions exist today?

const displayMediaOptions = {
  video: {
    displaySurface: "browser",
  },
  audio: {
    suppressLocalAudioPlayback: false,
  },
  preferCurrentTab: false,
  selfBrowserSurface: "exclude",
  systemAudio: "include",
  surfaceSwitching: "include",
  monitorTypeSurfaces: "include",
};

async function startCapture(displayMediaOptions) {
  let captureStream = null;

  try {
    captureStream =
      await navigator.mediaDevices.getDisplayMedia(displayMediaOptions);
  } catch (err) {
    console.error(`Error: ${err}`);
  }
  return captureStream;
}

How would you solve it?

Implementation Proposal

  1. API Design

    • window.screenshot.capture(options)
      • options can include:
        • target: Element or full viewport
        • format: Desired image format
        • quality: Quality setting for lossy formats like JPEG
    • window.screenshot.export(options)
      • options can include:
        • format: Desired export format
        • filename: Suggested filename for download
  2. Security Considerations

    • Implement user consent prompts.
    • Limit the frequency of screenshots to prevent abuse.
    • Ensure screenshots do not capture sensitive information without user knowledge.
  3. Performance Considerations

    • Optimize for minimal impact on browser performance.
    • Provide asynchronous operations to prevent blocking the main thread.

Anything else?

Maybe we can have a single API to capture screenshot as well as record the screen.

BlobTheKat commented 1 week ago

This is a problematic feature: taking a screenshot of an element is something that should not require user consent: after all, the API would be triggered by its own page

On the other hand, I believe being able to capture tainted canvases and crossorigin iframes should not be allowed even by user consent: the user is likely not aware of what parts of the page are tainted or iframed: their consent is mostly meaningless