Keyboard presses, hover, drag and drop, right-click menus, and JavaScript alerts with page.once() and page.on()

• Keyboard presses and shortcuts, checked with screenshots
• Hover: open a menu, then click what it reveals
• Drag and drop with dragTo()
• The Kanban interview question: when dragTo() does nothing, drive the mouse with boundingBox()
• A full HD viewport in the config
• Right-click, and reading a context menu
• JavaScript alerts, and how they differ from modals and pop-ups
• test.describe and beforeEach
• page.once() versus page.on(), and why the listener goes first
• Running the tests in a describe block in parallel or in series
• Three tasks: the hover menu, the second Kanban card, and Automation Challenge 1

page.keyboard is an interface hanging off the page, with a method for every kind of key event. The first spec presses keys on a key code viewer and takes a screenshot after each one to prove it landed:

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

test('Verify the TestCase', async ({ page }) => {
   await page.goto("https://keycode.info");

   await page.keyboard.press('A');
   await page.screenshot({ path: 'A.png' });

   await page.keyboard.press('ArrowLeft');
   await page.screenshot({ path: 'ArrowLeft.png' });


   await page.keyboard.press('Shift+O');
   await page.screenshot({ path: 'O.png' });

   await page.keyboard.up("Shift");
   await page.keyboard.down("Shift");


   await page.pause();
});

• press() takes a character ('A'), a named key ('ArrowLeft'), or a combination ('Shift+O'). In a combination, Playwright holds the modifier down and releases it for you.
• screenshot({ path }) saves a PNG. A bare file name lands in the folder you ran the tests from, which is why the repo's .gitignore now lists A.png, O.png and ArrowLeft.png. Give it a folder, such as screenshots/A.png, to keep them together.

The hover demo used SpiceJet's site: hover the Add-ons menu, then click the FlyEarly item it reveals. The spec file was overwritten during class, so this version is reconstructed from the recording:

await page.goto('https://www.spicejet.com/');
await page.getByText('Add-ons', { exact: true }).hover();
await page.getByText('FlyEarly', { exact: true }).click();

There is no mouse down, mouse up or Actions class as in Selenium: find the element and call hover(). exact: true makes getByText() match the whole string rather than any text containing it.

On the live site the item is written as one word, FlyEarly, so exact: true needs that spelling; "Fly Early" with a space matches nothing. Clicking it opens a new tab, which belongs to the windows topic still to come.

The same pattern works on the hover menu practice page, which is today's first task.

For a simple drag, dragTo() is one line: locate the source, locate the target, and drag one onto the other.

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

test('Verify Hover for the spicejet', async ({ page }) => {
     await page.goto('https://the-internet.herokuapp.com/drag_and_drop');

    const columnA = page.locator('#column-a');
    const columnB = page.locator('#column-b');

    await columnA.dragTo(columnB);
    await page.pause();

   await page.pause();
});

After the drag the two column headers read B and A: the boxes have swapped. The test title is left over from the hover spec.

The interview version: on the Testing Academy Kanban board, move a card from To Do to In Progress, as you would in Jira. Each card is an article holding a heading, a div and spans. dragTo() with the card and the In Progress column runs without an error, and the card stays exactly where it was.

What works is driving the mouse yourself:

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

test('Verify Drag and Drop in Kanban Board', async ({ page }) => {
    await page.goto('https://app.thetestingacademy.com/playwright/widgets/dnd');


    let source:Locator = page.locator('#card-write-spec');
    const sBox = (await source.boundingBox())!;

    let target: Locator = page.locator('[data-status="in-progress"]');
    const tBox = (await target.boundingBox())!;

    await page.mouse.move(sBox.x + sBox.width / 2, sBox.y + sBox.height / 2);
    await page.mouse.down();
    await page.mouse.move(tBox.x + tBox.width / 2, tBox.y + tBox.height / 2, { steps: 10 });
    await page.mouse.up();


    await page.pause();
});

The card ends up in the In Progress column. page.mouse works in pixels, not locators, which is what boundingBox() is for: it returns the element's x, y, width and height on the page.

• The center is x + width / 2 across and y + height / 2 down: not a formula to memorise, just half the box each way. The class compared it to lifting a person by their center of mass rather than their head.
• steps: 10 moves the mouse in ten small increments instead of one jump. The class called the number trial and error.
• The ! after boundingBox() tells TypeScript the result is not null. It returns null for an element that is not rendered.

A full HD window. While the board was on screen, the class set the viewport to 1920 by 1080 in playwright.config.ts. The pushed config sets it in two places, and the comment explains why:

  use: {
    /* Base URL to use in actions like `await page.goto('')`. */
    // baseURL: 'http://localhost:3000',

    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
    trace: 'on-first-retry',
    headless: false,
    /* Full HD. The project below re-applies it after the device spread, because
       devices['Desktop Chrome'] carries its own 1280x720 viewport and
       project-level `use` wins over this config-level `use`. */
    viewport: { width: 1920, height: 1080 },
  },

  /* Configure projects for major browsers */
  projects: [
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        viewport: { width: 1920, height: 1080 },
      },
    }]

That checks out: with the viewport set only at the top level, the page opens at 1280 by 720.

click({ button: 'right' }) is a right-click, and allInnerTexts() reads every option in the menu that opens:

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

test('Verify Drag and Drop in Kanban Board', async ({ page }) => {
    await page.goto('https://app.thetestingacademy.com/playwright/widgets/context-menu');

    await page.locator('span.context-menu-one').first().click({ button: 'right' });

   const allOptions: string[] = await page
        .locator('ul.context-menu-list span')
        .allInnerTexts();
    console.log(allOptions);

    await page.getByText('Copy', { exact: true }).first().click();

    await page.pause();
});

[
  'Edit',   '⌘E',
  'Cut',    '⌘X',
  'Copy',   '⌘C',
  'Paste',  '⌘V',
  'Delete', '⌫',
  'Quit',   '⌘Q'
]

Six menu items, twelve strings: each item holds a label span and a shortcut span, and the selector catches both. ul.context-menu-list span:not(.ctx-shortcut) returns just the six labels. Double-click works the same way, with dblclick().

Three things get called "pop-ups", and only one of them is a JavaScript dialog:

• JavaScript dialogs: alert (OK), confirm (OK or Cancel) and prompt (a text box, then OK or Cancel). The page's JavaScript opens them, but the browser draws them, so they are not in the DOM and you cannot locate them. Playwright hands them to you through the dialog event.
• Modals, such as the login overlay on MakeMyTrip, are plain HTML on the page. Locate their buttons like any other element.
• Pop-ups, new windows and tabs, are a separate topic, coming up.

With no listener registered, Playwright dismisses every dialog itself: an alert just closes, and a confirm reports "You clicked: Cancel".

The alerts spec puts three tests in one test.describe group, with a beforeEach that opens the page before every one of them, so the goto runs three times. For anyone coming from Selenium, it works like a TestNG before-method annotation.

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

test.describe('Javascript Alerts', () => {
    test.beforeEach(async ({ page }) => {
        await page.goto('https://the-internet.herokuapp.com/javascript_alerts');
    });



    test('JS Alert accept 1', async ({ page }) => {


        await page.getByRole('button', { name: "Click for JS Alert" }).click();
        page.once('dialog', async dialog => {
            console.log('Alert type:', dialog.type());
            console.log('Alert message:', dialog.message());
            expect(dialog.message()).toBe('I am a JS Alert');
            await dialog.accept();
        });
        await page.pause();
    });
    test('JS Alert accept 2', async ({ page }) => {

        page.once('dialog', async dialog => {
            console.log('Alert type:', dialog.type());
            expect(dialog.type()).toBe('confirm');
            console.log('Alert message:', dialog.message());
            expect(dialog.message()).toBe('I am a JS Confirm');
            await dialog.accept();
            //await dialog.dismiss();
        });

        await page.locator('button', { hasText: 'Click for JS Confirm' }).click();
        await expect(page.locator('#result')).toHaveText('You clicked: Ok');






    });
    test('JS Alert accept 3', async ({ page }) => {

        const inputText = 'Hello from The Testing Academy';

        page.once('dialog', async dialog => {
            expect(dialog.type()).toBe('prompt');
            expect(dialog.defaultValue()).toBe('');
            await dialog.accept(inputText);
            //await dialog.dismiss();
        });

        await page.locator('button', { hasText: 'Click for JS Prompt' }).click();
        await expect(page.locator('#result')).toHaveText(`You entered: ${inputText}`);







    });
});

All three pass, and the run prints:

Alert type: confirm
Alert message: I am a JS Confirm

Only test 2 printed anything. Test 1 has the same two console.log lines and printed nothing, which is the subject of the next section.

• Confirm: dialog.accept() is OK, and dialog.dismiss() is Cancel.
• Prompt: dialog.accept(text) types into the box before pressing OK, and dialog.defaultValue() is whatever the box held to start with.
• dialog.type() and dialog.message() tell you which kind of dialog opened and what it said.

Both register a listener for an event; the difference is how long it lasts.

Clicking an alert button three times confirms the last row: page.on ran three times, and page.once ran once.

The listener goes first. Test 1 registers its listener after the click. The alert opens during the click, finds no listener, and Playwright dismisses it. The page.once() registered afterwards waits for a dialog that never comes, so its logs and its expect() never run, and the test passes without checking anything. The class tried this order live and it appeared to work, for exactly that reason. Moving the listener above the click gives:

Alert type: alert
Alert message: I am a JS Alert

An expect() inside a handler that does run fails the test as you would hope, whether it comes before or after accept(). The trap is only the handler that never runs.

The dialog event is one of many a page emits. The others include console, request, response, popup, download, pageerror, framenavigated, websocket, worker, close, crash and filechooser, all registered the same way.

The batch config sets fullyParallel: true, so the three tests in the describe block run in parallel, spread across workers. The class first described them as sequential by default, then corrected itself: it is the config that makes them parallel. To run a group in order, use test.describe.serial(...) in place of test.describe(...).

• Code: all six specs are in the batch repo, in tests/10_Keyboard_Hover_Drag_Drop_Calender and tests/11_JS_Alerts.
• Practise more on the Playwright practice pages: right-click, keyboard, windows and tabs, upload and download, and toast notifications.
• Still to come: pop-ups and new windows, toast messages, and shadow DOM.