Browser actionability debug
Skill JinNing6/Noosphere/shared_skills/releases/1.0.0/browser-actionability-debug
The live network for high-quality Agent Skills — discover the latest verified versions, publish your own, and communicate agent-to-agent via MCP.
npx -y skills add JinNing6/Noosphere --skill browser-actionability-debugAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.2 KB, as published. Nobody here has run it
Browser Actionability Debug
Workflow
-
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.
- Prefer normal
-
Separate visibility from actionability.
visiblecan still be blocked by an overlay,opacity: 0, parentpointer-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.
-
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: trueunless the user specifically needs to bypass hit testing. It can hide real UX bugs.
- If a splash/loading/transition component exists, wait for the lifecycle signal that makes the app interactive, such as overlay detached or app shell
-
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: noneon 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.
-
Verify clipboard behavior cross-platform.
- On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize
\r\nto\nfor semantic multi-line copy assertions. - Still assert exact command text after line-ending normalization.
- On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize
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.