[Bug]: Some firefox installations has problems with Mui DatePicker

[Tockra]

Version

1.49.1

Steps to reproduce

1. Build a test which tries to fill a input, which was created by muis DatePicker. E.g.

  test(`test`, async ({ page }) => {
    await page.goto("https://mui.com/x/react-date-pickers/date-picker/");

    const element = page.locator('input[id=":R6lal9l6kud6:"]');
    await element.waitFor();
    await element.fill("12/12/2024");

    await expect(element).toHaveValue("12/12/2024");
  });

2. Run this test in a docker container based on node:22-bookworm-slim
3. See the test failing in firefox (132.0) (https://playwright.azureedge.net/builds/firefox/1466/firefox-debian-12.zip)

-> On my local setup everything works fine (same firefox version, but on a arm macos system (https://playwright.azureedge.net/builds/firefox/1466/firefox-mac-arm64.zip))

Expected behavior

Working test, which can fill values into a input element which was created by a DatePicker.

Actual behavior

    Error: locator.waitFor: Test timeout of 15000ms exceeded.
    Call log:
      - waiting for locator('input[id=":R6lal9l6kud6:"]') to be visible


      23 |
      24 |     const element = page.locator('input[id=":R6lal9l6kud6:"]');
    > 25 |     await element.waitFor();
         |                   ^
      26 |     await element.fill("12/12/2024");
      27 |
      28 |     await expect(element).toHaveValue("12/12/2024");
        at /mnt/ember-web/tests/invoices.spec.ts:25:19

Additional context

No response

Environment

System:
    OS: Linux 6.8 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (16) x64 AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
    Memory: 58.56 GB / 61.92 GB
    Container: Yes
  Binaries:
    Node: 22.11.0 - /usr/local/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 10.9.2 - /mnt/ember-web/node_modules/.bin/npm
  Languages:
    Bash: 5.2.15 - /usr/bin/bash
  npmPackages:
    @playwright/test: ^1.46.1 => 1.49.1
    playwright: ^1.46.1 => 1.49.1

[yury-s]

On Linux, it passes in headed in Firefox and fails in headless. Looks like some issue with the implementation of headless in Firefox. What I don't understand is why the page renders element input[id=":r1:"] instead of input[id=":R6lal9l6kud6:"], probably some feature detection that affects the behavior.

[yury-s]

Related issue: #32236

[Tockra]

What I don't understand is why the page renders element input[id=":r1:"] instead of input[id=":R6lal9l6kud6:"], probably some feature detection that affects the behavior.

This was the most difficult part while writing this example test...

Related issue: #32236

I'm not sure if this is the same issue. The author there talks about issues with chrome and firefox, but I observe this behavior only on firefox.

But I does not see any solution at the moment. This is very annoying.

[Tockra]

No further information here?
If there is no fix, I'm forced to change all test implementations to cypress or something else :(