Popover anchorEl console.warn spam in jsdom in MUI 7.3.8

[joshkel]

Steps to reproduce

Steps:

1. Clone the repo at https://github.com/joshkel/mui-jsdom-anchorel-bug
2. pnpm i
3. pnpm t
4. Note the anchorEl warnings in the console.
5. Compare with MUI 7.3.7, which did not have these warnings.

Current behavior

Warnings and errors about invalid anchorEl in the console.

  console.warn
    MUI: The `anchorEl` prop provided to the component is invalid.
    The anchor element should be part of the document layout.
    Make sure the element is present in the document or that it's not display none.

      28 |     render(<TestSelect />);
      29 |
    > 30 |     fireEvent.mouseDown(screen.getByLabelText('Age'));
         |               ^
      31 |     fireEvent.click(screen.getByText('Twenty'));
      32 |   });
      33 | });

      at node_modules/.pnpm/@mui+material@7.3.8_@emotion+react@11.14.0_@types+react@18.3.28_react@18.3.1__@emotion+_c717ef74b561a9170687cdfe6f8fd663/node_modules/@mui/material/Popover/Popover.js:161:17
      at node_modules/.pnpm/@mui+material@7.3.8_@emotion+react@11.14.0_@types+react@18.3.28_react@18.3.1__@emotion+_c717ef74b561a9170687cdfe6f8fd663/node_modules/@mui/material/Popover/Popover.js:194:26
      at node_modules/.pnpm/@mui+material@7.3.8_@emotion+react@11.14.0_@types+react@18.3.28_react@18.3.1__@emotion+_c717ef74b561a9170687cdfe6f8fd663/node_modules/@mui/material/Popover/Popover.js:247:25

Expected behavior

No log spam; no significant behavior changes from 7.3.7.

Context

As a result of #47692, MUI now warns about "invalid" anchorEl properties in test environments. This causes a problem for test environments such as Jest with jsdom: it's my understanding that jsdom doesn't contain a layout engine, so all elements within jsdom have 0 dimensions, so checks such as

material-ui/packages/mui-material/src/Popover/Popover.js

Lines 169 to 183 in 1ee94a2

	if (
	!globalThis.MUI_TEST_ENV &&
	box.top === 0 &&
	box.left === 0 &&
	box.right === 0 &&
	box.bottom === 0
	) {
	console.warn(
	[
	'MUI: The `anchorEl` prop provided to the component is invalid.',
	'The anchor element should be part of the document layout.',
	"Make sure the element is present in the document or that it's not display none.",
	].join('\n'),
	);
	}

trigger even for "valid" anchorEl values.

What's the recommended way to use MUI in a test environment? I see in #47692 that globalThis.MUI_TEST_ENV is implemented, but it sounds like that's undocumented and intended for internal use only. I suspect that use in jsdom is common enough that going back to the previous behavior of process.env.NODE_ENV === 'test' would be better.

Your environment

npx @mui/envinfo

  System:
    OS: macOS 15.7.3
  Binaries:
    Node: 24.13.0 - /Users/josh/.nvm/versions/node/v24.13.0/bin/node
    npm: 11.6.2 - /Users/josh/.nvm/versions/node/v24.13.0/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 144.0.7559.133
    Edge: 145.0.3800.58
    Firefox: 147.0.4
    Safari: 26.2
  npmPackages:
    @base-ui/utils:  0.2.3 
    @emotion/react:  11.14.0 
    @emotion/styled:  11.14.1 
    @mui/core-downloads-tracker:  7.3.8 
    @mui/icons-material:  7.3.8 
    @mui/lab:  7.0.1-beta.22 
    @mui/material:  7.3.8 
    @mui/private-theming:  7.3.8 
    @mui/styled-engine:  7.3.8 
    @mui/system:  7.3.8 
    @mui/types:  7.4.11 
    @mui/utils:  7.3.8 
    @mui/x-date-pickers:  8.27.0 
    @mui/x-internals:  8.26.0 
    @mui/x-tree-view:  8.27.1 
    @types/react: ^18.3.27 => 18.3.27 
    react: ^18.3.1 => 18.3.1 
    react-dom: ^18.3.1 => 18.3.1 
    typescript: ^5.9.3 => 5.9.3 

Search keywords: popover anchorel

[linear]

MAT-1765

[Janpot]

material-ui/packages/mui-material/src/Popover/Popover.js

Lines 169 to 183 in 1ee94a2

	if (
	!globalThis.MUI_TEST_ENV &&
	box.top === 0 &&
	box.left === 0 &&
	box.right === 0 &&
	box.bottom === 0
	) {
	console.warn(
	[
	'MUI: The `anchorEl` prop provided to the component is invalid.',
	'The anchor element should be part of the document layout.',
	"Make sure the element is present in the document or that it's not display none.",
	].join('\n'),
	);
	}

🤔 If this branch is only needed for JSDOM, I'm thinking we could just feature detect it instead of relying on process.env.NODE_ENV nor globalThis.MUI_TEST_ENV. Currently we would branch into it for browser tests as well I suppose, which is undesired.

if (process.env.NODE_ENV !== 'production' && navigator.userAgent.includes("jsdom")) {
  // JSDOM only logic...
}

edit: though other incomplete dom implementations may fail as well, happy-dom.

edit 2: As we ran into this as well, I think the best way to think about testing is to set up your test env to ignore or expect certain warnings. Altering behavior of the library when a test env is detected is always going to be less robust.

[joshkel]

I think the best way to think about testing is to set up your test env to ignore or expect certain warnings. Altering behavior of the library when a test env is detected is always going to be less robust.

I agree that altering behavior of the library based on test env is less robust, but I disagree that it shouldn't be done - rather, it becomes one of several potentially competing design criteria.

To me, it's in part a question of DX (developer experience) - I want the code I work on to "just work," to be a joy for others to use, and I appreciate it when code I use takes the same approach. I therefore appreciate libraries that go to extra effort to accommodate common usage scenarios, even if that means a bit more internal complexity. (MUI in general does really well here - robust docs with fantastic interactive examples, good types, highly customizable, transparent development process.) And there's a question of tradeoffs: an internal project, with more limited resources and with focused maintainers who can more easily learn its specifics, may choose to prioritize robustness. But MUI is very widely used - I appreciate it when it's willing to make investments to save downstream developers' time, instead of shifting costs onto a potentially large number of downstream projects.

From another perspective, altering runtime behavior based on test environment is, as you say, brittle. But this isn't really a question of runtime behavior: these console.warn messages only exist for developers' benefit and have no meaningful runtime effect, so we're already in the realm of DX (developer experience). Given that, choosing to invest in warnings for invalid properties but not invest in ensuring that those warnings handle common test environments feels... arbitrary? If the goal is to not vary implementation based on test vs. non-test, then I could even argue that the warning logic is a bug: there are commonly used DOM implementations (jsdom and happy-dom) for which the warnings give false positives, and MUI generally supports using these DOM implementations (as far as I can tell), so Popover should either support jsdom or (for consistency with these MUI components I linked to) at least document the limitation with workarounds.

And, on a purely practical and selfish level, this was a SemVer patch release whose only notice was a terse "[code-infra] Remove usage of NODE_ENV=test" line in the changelog, but I now have tens of thousands of lines of log spam, across hundreds of tests, and a few dozen test failures (because they asserted on specific console.warn / console.error outputs).

Thank you for your time, and thank you for your work on MUI.

[kimballa]

As a workaround that others may find helpful, Cursor correctly identified that the MUI_TEST_ENV flag works. Put the following line at the top of your jest.setup.ts, after any imports:

// Suppress MUI anchorEl "not in document layout" warnings in jsdom (zero-sized rects).
(globalThis as any).MUI_TEST_ENV = true;

Your tests will no longer emit the spurious warning spam to the console.