Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

take_snapshot appears blank on <canvas>/WebGL and lazy-a11y canvas UIs

Open Beginner friendly
  • Is something wrong?
#3,225 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
Half a day
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
accessibility, developer-experience

Research direction

Start with the snapshot creation in src/TextSnapshot.ts and the existing pruning note in src/formatters/SnapshotFormatter.ts; reproduce with a page containing a visible <canvas>. Determine whether to add a canvas-specific hint and update skills/a11y-debugging/SKILL.md and skills/chrome-devtools/SKILL.md. Done means nonverbose snapshots explain why canvas content may be absent and direct users to screenshots, verbose mode, or an accessibility placeholder, with appropriate snapshot tests.

Written by the indexing model from the issue text.

Description

collecting-feedback feature

When an agent follows skills/chrome-devtools/SKILL.md ("Prefer take_snapshot over take_screenshot" to inspect page state) on a <canvas>-rendered page—such as a 3D WebGL/Three.js scene, a canvas chart/game, or a canvas UI toolkit—take_snapshot returns an empty RootWebArea (or a single accessibility-opt-in trigger button) with zero application content, leading the agent to assume the page failed to render.

Two ways this hits <canvas> applications in practice
  1. Unlabelled <canvas> elements are pruned by default (verbose: false):
    • In src/TextSnapshot.ts#L59-L63, default take_snapshot runs page.pptrPage.accessibility.snapshot({ includeIframes: true, interestingOnly: !verbose }).
    • Because Chromium's interestingOnly: true filter drops <canvas> nodes that lack explicit ARIA attributes, a full-viewport WebGL/Three.js or 2D canvas app produces a snapshot with no <canvas> node at all—so the agent does not even know the viewport is driven by a canvas that requires take_screenshot or verbose: true.
  2. Deferred / opt-in DOM accessibility trees on canvas UI engines:
    • Canvas-based UI frameworks and document editors (e.g. Flutter Web canvaskit/skwasm, Compose Multiplatform for Web, or canvas document viewers) avoid maintaining thousands of hidden DOM accessibility nodes at 60fps until assistive technology clicks an offscreen opt-in element (such as <flt-semantics-placeholder aria-label="Enable accessibility" role="button">).
    • Until that trigger is activated, take_snapshot and a11y-debugging see only a single button "Enable accessibility" and 0 application controls.
Possible directions
  • When take_snapshot (verbose: false) returns an almost-empty AX tree on a page that contains a visible <canvas> (similar to the existing note in src/formatters/SnapshotFormatter.ts#L383-L390 when a selected DevTools element is pruned by interestingOnly), include a note indicating that a <canvas> is present and suggesting take_screenshot, verbose: true, or activating any accessibility opt-in placeholder.
  • Note in skills/a11y-debugging/SKILL.md (and skills/chrome-devtools/SKILL.md) that canvas-rendered apps may require take_screenshot or clicking an "Enable accessibility" placeholder before inspecting the AX tree.
Dominant language
TypeScript
Stars
54.1k
Forks
6.3k
Avg merge
1d 17h
Merged PRs (30d)
241

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ChromeDevTools/chrome-devtools-mcp

All issues in ChromeDevTools/chrome-devtools-mcp

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.