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.
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.
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.
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.
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.
1---2name: browser-actionability-debug3description: 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.4---56# Browser Actionability Debug78## Workflow9101. Reproduce the failure with a real browser action, not only DOM existence.11 - Prefer normal `locator.click()` first so the browser reports what intercepts the pointer.12 - Read the full call log. If it names an intercepting element, treat that as evidence.13142. Separate visibility from actionability.15 - `visible` can still be blocked by an overlay, `opacity: 0`, parent `pointer-events: none`, a splash screen, or an element with higher stacking order.16 - Inspect `elementFromPoint()` at the target center and compare it to the intended button/input.17 - Capture computed `opacity`, `visibility`, `display`, `pointerEvents`, and bounding boxes for the target and its stable ancestors.18193. Check lifecycle gates before changing CSS.20 - 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`.21 - Do not fix a test by using `force: true` unless the user specifically needs to bypass hit testing. It can hide real UX bugs.22234. Fix at the correct layer.24 - If the overlay should still be active, update the test to wait for the overlay to detach.25 - If a decorative canvas or visual layer should never capture input, set `pointer-events: none` on that visual layer.26 - If app content is intentionally disabled until boot, do not make underlying controls clickable before boot unless that is a product decision.27285. Verify clipboard behavior cross-platform.29 - On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize `\r\n` to `\n` for semantic multi-line copy assertions.30 - Still assert exact command text after line-ending normalization.3132## Diagnostic Snippet3334Use this inside `page.evaluate()` when a click target exists but is not actionable:3536```js37const target = document.querySelector('[aria-label="Copy Noosphere share post"]');38const rect = target?.getBoundingClientRect();39const top = rect40 ? document.elementFromPoint(rect.left + rect.width / 2, rect.top + rect.height / 2)41 : null;4243return {44 target: target ? getComputedStyle(target).cssText : null,45 topTag: top?.tagName,46 topClass: String(top?.className || ''),47 topAria: top?.getAttribute?.('aria-label') || null,48 targetRect: rect ? {49 x: rect.x,50 y: rect.y,51 width: rect.width,52 height: rect.height,53 } : null,54};55```5657## Completion Standard5859- The original browser action succeeds without `force: true`.60- The target is within the tested viewport.61- `elementFromPoint()` at the target center resolves to the target or a child of it.62- Clipboard assertions normalize OS line endings but otherwise match exactly.63- Dev servers and temporary browser dependencies are stopped or removed after verification.