AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified Apache-2.0 Self-run

Browser Actionability Debug

skill-jinning6-noosphere-browser-actionability-debug · by JinNing6

Diagnose browser UI tests or real browser checks where an element appears visible but cannot be clicked, copied, hovered, or focused. Use for Playwright/Chrome/browser automation failures involving overlays, splash screens, opacity transitions, pointer-events, elementFromPoint mismatches, clipboard assertions, or differences between "visible" and actually actionable UI.

No reviews yet
0 installs
6 views
0.0% view→install

Install

$ agentstack add skill-jinning6-noosphere-browser-actionability-debug

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-jinning6-noosphere-browser-actionability-debug)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
23d ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Browser Actionability Debug? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Browser Actionability Debug

Workflow

  1. Reproduce the failure with a real browser action, not only DOM existence.
  • Prefer normal locator.click() first so the browser reports what intercepts the pointer.
  • Read the full call log. If it names an intercepting element, treat that as evidence.
  1. Separate visibility from actionability.
  • visible can still be blocked by an overlay, opacity: 0, parent pointer-events: none, a splash screen, or an element with higher stacking order.
  • Inspect elementFromPoint() at the target center and compare it to the intended button/input.
  • Capture computed opacity, visibility, display, pointerEvents, and bounding boxes for the target and its stable ancestors.
  1. Check lifecycle gates before changing CSS.
  • If a splash/loading/transition component exists, wait for the lifecycle signal that makes the app interactive, such as overlay detached or app shell pointer-events: auto.
  • Do not fix a test by using force: true unless the user specifically needs to bypass hit testing. It can hide real UX bugs.
  1. Fix at the correct layer.
  • If the overlay should still be active, update the test to wait for the overlay to detach.
  • If a decorative canvas or visual layer should never capture input, set pointer-events: none on that visual layer.
  • If app content is intentionally disabled until boot, do not make underlying controls clickable before boot unless that is a product decision.
  1. Verify clipboard behavior cross-platform.
  • On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize \r\n to \n for semantic multi-line copy assertions.
  • Still assert exact command text after line-ending normalization.

Diagnostic Snippet

Use this inside page.evaluate() when a click target exists but is not actionable:

const target = document.querySelector('[aria-label="Copy Noosphere share post"]');
const rect = target?.getBoundingClientRect();
const top = rect
  ? document.elementFromPoint(rect.left + rect.width / 2, rect.top + rect.height / 2)
  : null;

return {
  target: target ? getComputedStyle(target).cssText : null,
  topTag: top?.tagName,
  topClass: String(top?.className || ''),
  topAria: top?.getAttribute?.('aria-label') || null,
  targetRect: rect ? {
    x: rect.x,
    y: rect.y,
    width: rect.width,
    height: rect.height,
  } : null,
};

Completion Standard

  • The original browser action succeeds without force: true.
  • The target is within the tested viewport.
  • elementFromPoint() at the target center resolves to the target or a child of it.
  • Clipboard assertions normalize OS line endings but otherwise match exactly.
  • Dev servers and temporary browser dependencies are stopped or removed after verification.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.