[BUG] type() is misleading, does not actually press keys if character requires a modifier key held

[WestonThayer]

System info

• Playwright Version: v1.37.1
• Operating System: All
• Browser: All
• Other info:

Source code

• I provided exact source code that allows reproducing the issue locally.

Config file

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'], },
    },
  ]
});

Test file (self-contained)

it('should check the box using setChecked', async ({ page }) => {
  await page.setContent(`
<input id="input"></input>
<script>
window.__keyLog = "";
document.getElementById("input").addEventListener("keydown", (e) => {
  window.__keyLog += e.code + ",";
});
</script>
`);

  await page.locator("#input").type("ABC");
  const keyLog = await page.evaluate("window.__keyLog");
  expect(keyLog).toContain("Shift");
});

Steps

• Run the test

Expected

keyLog is something like ShiftLeft,KeyA,ShiftLeft,KeyB,ShiftLeft,KeyC, .

Actual

keyLog is KeyA,KeyB,KeyC, .

Notes

I see that #24614 changes to pressSequentially(), but it appears to use type() under the hood, so shouldn't make a difference.

I think the issue is that

playwright/packages/playwright-core/src/server/input.ts

Lines 87 to 98 in a34030b

	async type(text: string, options?: { delay?: number }) {
	const delay = (options && options.delay) || undefined;
	for (const char of text) {
	if (usKeyboardLayout.has(char)) {
	await this.press(char, { delay });
	} else {
	if (delay)
	await new Promise(f => setTimeout(f, delay));
	await this.insertText(char);
	}
	}
	}

calls insertText when a modifier key would be required, which for Chromium eventually calls https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-insertText.

I find this misleading, especially for the Page.keyboard.type API — I expect it to exactly emulate the events a human typing on a real keyboard would generate.

[pavelfeldman]

I find this misleading, especially for the Page.keyboard.type API — I expect it to exactly emulate the events a human typing on a real keyboard would generate.

Pressing 'a' without Shift while having Caps Lock on will produce upper-case 'A'. And pressing 'Shift+a' will produce lower-case 'a'. In the general case there is no correlation between Shift and the case. To not think about this, in Playwright:

• Pressing either 'a' or 'A' on US keyboard produces code=KeyA, event.which=65
• Pressing 'a' produces event.key=a and pressing 'A' produces event.key=A, regardless of the combination of Caps and Shift.

Press and type are low-level APIs, so if you want to simulate typing with shift, you should hold shift, type all caps and then release shift. That way you have direct keyboard simulation.

[WestonThayer]

Thanks for considering. My mental model was type() is more of a convenience method to avoid needing to page.keyboard.down("Shift"); page.keyboard.press("KeyA"); page.keyboard.up("Shift");, which makes sense to me it can't guarantee that a "A" will be typed.

I thought fill() was for when you cared more about injecting the right string. Although... now that I think about it fill() doesn't cover the case where the UI requires filling char by char with a delay, so I see how type() fills that need.

As an aside, it seems worth noting that #16214 means the Caps Lock case can't occur currently.

Here's a convenience method implementation in case it helps anyone else: https://gist.github.com/WestonThayer/da07c2dc6f4bb9447187fdbdfb4fff07