How to Test Right Click Menu in Playwright: Complete Context Menu Testing Guide

1. Why Testing Context Menus Is Harder Than It Looks

Custom context menus (right-click menus) are one of the most deceptively tricky UI patterns to test with end-to-end tools. Unlike a regular click handler, a context menu depends on the contextmenu browser event, which must be dispatched with precise clientX and clientY coordinates. The menu component then reads those coordinates to position itself relative to the cursor. If your test triggers the event without coordinates, the menu may render at (0, 0) or not appear at all.

The complexity grows quickly. Most production context menus support nested sub-menus that open on hover or arrow key navigation. Each sub-menu must be positioned so it does not overflow the viewport, which means edge cases at window borders. The menu must close when the user clicks outside of it, presses Escape, scrolls the page, or switches tabs. It must also support full keyboard navigation: Arrow Down and Arrow Up to move between items, Arrow Right to open a sub-menu, Arrow Left to close it, Enter to activate, and Home/End to jump to the first or last item. According to the WAI-ARIA Menu Pattern, all of these keyboard interactions are expected for an accessible menu widget.

There are five structural reasons context menu testing breaks in practice. First, Playwright's click({ button: 'right' }) dispatches a real contextmenu event, but many tutorials incorrectly use dispatchEvent without coordinates, producing a synthetic event that skips the positioning logic. Second, the menu is often rendered via a portal (attached to document.body rather than the triggering element), so locators scoped to the parent container will miss it. Third, sub-menus open on hover with a debounce delay, and tests that move the mouse too quickly will never see the sub-menu appear. Fourth, the menu can be conditionally rendered based on what was right-clicked (different items for files vs. folders, for example), so your test must right-click the exact target. Fifth, browser-native context menus can interfere: if the app fails to call preventDefault() on the contextmenu event, the native browser menu appears on top of the custom one, and Playwright cannot interact with native browser menus at all.

2. Setting Up a Reliable Test Environment

Context menu tests are sensitive to viewport size. A menu that fits comfortably at a 1280x720 viewport may overflow and reposition at 800x600. Pin your viewport in the Playwright config to get deterministic positioning results.

You also need a page with a custom context menu to test against. For this guide, we will use a file manager UI where right-clicking a file row opens a context menu with actions like Rename, Delete, Copy Path, and a “Move to” sub-menu with folder options. This is a common real-world pattern seen in applications like VS Code, Figma, Notion, and Google Drive.

Test Helper: Triggering the Context Menu

Playwright's built-in click({ button: 'right' }) is the correct way to trigger a context menu. It dispatches a real contextmenu event with valid coordinates based on where the target element is in the viewport. Avoid using page.dispatchEvent() manually unless you need to right-click at a specific pixel offset within an element.

9. Common Pitfalls That Break Context Menu Tests

These pitfalls are sourced from real Playwright GitHub issues and Stack Overflow threads. Each one has caused production test suites to fail intermittently or completely.

What Good Context Menu Tests Look Like

10. Writing Context Menu Tests in Plain English with Assrt

The Playwright scenarios above total around 300 lines of TypeScript across six test files. Each test contains implementation details like getByRole('menu'), boundingBox(), and keyboard.press('ArrowDown') that couple the test to the menu component's DOM structure. When your team refactors the context menu (swapping Radix UI for a custom implementation, changing from portal rendering to inline, updating ARIA roles), every test file breaks.

Assrt lets you describe context menu behavior in plain English. Each .assrtfile declares what to test, not how to find it. Assrt compiles these into real Playwright TypeScript, committed to your repo as runnable tests. When the menu's DOM structure changes, Assrt detects the failure, analyzes the updated markup, and opens a pull request with fixed selectors. Your scenario files remain stable.

Seven scenarios, 65 lines of plain English. The equivalent Playwright TypeScript is approximately 300 lines across multiple files. When the menu component changes its rendering strategy, portal target, or ARIA structure, the Assrt scenarios stay the same. Assrt handles the locator updates automatically.

// tests/context-menu/basic.spec.ts (45 lines)
// tests/context-menu/positioning.spec.ts (75 lines)
// tests/context-menu/actions.spec.ts (55 lines)
// tests/context-menu/submenus.spec.ts (65 lines)
// tests/context-menu/keyboard.spec.ts (85 lines)
// tests/context-menu/dismiss.spec.ts (70 lines)

// 6 files, ~300 lines of Playwright TypeScript
// Every file coupled to DOM structure, ARIA roles,
// bounding box calculations, and keyboard event handling.

import { test, expect } from '@playwright/test';

test('right-click opens context menu', async ({ page }) => {
  await page.goto('/files');
  const fileRow = page.locator('[data-testid="file-row-report.pdf"]');
  await fileRow.click({ button: 'right' });
  const menu = page.getByRole('menu');
  await expect(menu).toBeVisible();
  // ... 280+ more lines across 6 files
});

Start with the basic right-click scenario. Once it passes in CI, add the positioning test, then the sub-menu hover, then keyboard navigation, and finally the dismiss scenarios. In one session you can achieve comprehensive context menu coverage that most applications never manage to build and maintain by hand.