:modal matching recursively calls Element.matches()` under jsdom since 2.2.26 #177

Description

Starting with nwsapi 2.2.26, matching :modal under jsdom causes a large number of recursive Element.matches() calls and a severe performance regression.

The issue is still present in:

• nwsapi 2.2.27, the latest npm release
• the current master branch at commit 2e9498f

The regression appears to come from commit 24cdab6, which introduced common native detection for display-state pseudo-classes.

Minimal reproduction

mkdir nwsapi-modal-repro
cd nwsapi-modal-repro
npm init -y
npm install [email protected] [email protected]

Create reproduce.js:

const { performance } = require('node:perf_hooks');
const { JSDOM } = require('jsdom');

const dom = new JSDOM('<!doctype html><html><body><div></div></body></html>');
const element = dom.window.document.body.firstElementChild;

const start = performance.now();

for (let index = 0; index < 10; index += 1) {
	element.matches(':modal');
}

console.log({
	nwsapi: require('nwsapi/package.json').version,
	durationMs: performance.now() - start,
});

Run:

node reproduce.js

Results

Tested with Node.js 24.15.0 and jsdom 20.0.3:

The exact timings vary, but the version boundary is consistent. Pinning nwsapi to 2.2.25 removes the slowdown.

Recursive call profile

Instrumenting Element.prototype.matches around one top-level element.matches(':modal') call produced:

In a downstream six-test Jest file using Floating UI, this expanded to approximately 127 million :fullscreen checks and caused tests to exceed a 50-second timeout.

Suspected cause

The new implementation contains this fallback:

matchesNative =
	function(node, selector) {
		var matcher = _matches || node.matches || node.webkitMatchesSelector ||
			node.mozMatchesSelector || node.msMatchesSelector;
		if (!matcher) return false;
		try {
			return matcher.call(node, selector);
		} catch (e) {
			return false;
		}
	},

isFullscreen =
	function(node) {
		var doc = node.ownerDocument;
		return matchesNative(node, ':fullscreen') || !!(doc && (
			doc.fullscreenElement === node ||
			doc.webkitFullscreenElement === node ||
			doc.mozFullScreenElement === node ||
			doc.msFullscreenElement === node));
	},

isModal =
	function(node) {
		return matchesNative(node, ':modal') || isFullscreen(node);
	},

jsdom implements Element.matches() by delegating to nwsapi. When nwsapi is used as jsdom's selector engine, _matches is not set through Dom.install(), so matchesNative() falls back to node.matches. That routes back into nwsapi:

jsdom Element.matches(':modal')
  -> nwsapi match(':modal')
    -> isModal()
      -> matchesNative(node, ':modal')
        -> jsdom Element.matches(':modal')
          -> nwsapi match(':modal')
          ...

isModal() also falls back to isFullscreen(), producing the much larger number of :fullscreen evaluations.

Expected behavior

Matching :modal or :fullscreen in an environment without native support should return the result derived from observable DOM state, or false, without recursively invoking the same selector engine.

Possible fix direction

matchesNative() should avoid falling back to node.matches when that method is backed by the current nwsapi instance. For example, the display-state helpers could use a genuinely preserved native matcher only, use observable DOM properties when available, and otherwise return false.

A re-entrancy guard around native detection may also prevent recursion, but avoiding the non-native fallback would address the underlying integration problem.

As a local check, I added a module-level re-entrancy flag around matcher.call(node, selector) and returned false from nested calls. On master at 2e9498f, this reduced the minimal reproduction from 3063.912 ms to 3.253 ms for ten :modal matches. This confirms the recursive path, although the preferred fix may depend on the browser compatibility expected from matchesNative().