What?

Updates JSDOM from v25 to v27 (25.0.1 to 27.2.0).

Why?

• Helps unblock UI: Add Stack component leveraging gap spacing design tokens #73308, since newer versions of JSDOM have better support for CSS properties
• As a regular maintenance task, keeping dependencies up to date reduces future burden and allows us to leverage bug fixes and features

How?

Besides updating the dependencies themselves, a few tests needed to be changed due to changes in behavior of JSDOM.

These fall into two buckets:

• Computed accessible names for many elements now frequently have whitespace eliminated where element boundaries exist in the DOM
• Differences in DOM selector support due to underlying migration from nwsapi to @asamuzakjp/dom-selector

For the first, a detailed explanation is available at #73308 (comment) :

It's an interesting nuance of computing accessible names and whether two adjacent elements are joined with any whitespace, where the browser renders these as <span>I'm an anchor link!</span><span aria-label="(opens in a new tab)"></span>. Apparently it's an ongoing discussion in the spec of computing accessible names. After digging into it, I've determined the root cause to be an interaction between dom-accessibility-api (which powers the getByRole name matching) and JSDOM, where dom-accessibility-api considers getPropertyValue('display') of an element. In earlier versions of JSDOM, a <span> would not report any value here, but in recent versions this is now 'inline'. Thus, the computed name has no space between the link text and the "(opens in a new tab)".

My read of the relevant specification is that this is a more accurate reflection of how a browser would be expected to behave:

§2.6.4 Name From Each Child: For each rendered child node of the current node:
[...]
§2.6.4.3 Append the result to the accumulated text.

For the second, I was able to confirm in a minimal reproduced example that @asamuzakjp/dom-selector's support of query selectors including HTML-encoded characters is not equivalent to how it would expect to behave in a real browser:

const { DOMSelector } = require('@asamuzakjp/dom-selector');
const { JSDOM } = require('jsdom');
const { window } = new JSDOM();
const { querySelector } = new DOMSelector(window);
container = window.document.createElement('div');
container.innerHTML = '<div id="&amp;gt;"></div>';
querySelector('[id="&gt;"]', container);
// null
// container.querySelector('[id="&gt;"]') would match in Chrome

It's not clear to me if this is a "bug", or if it's just a really bad idea to have HTML-encoded characters in an attribute like this and expect to be able to query it via querySelector. Technically it's not invalid per HTML5.

From what I could tell with the affected usage in <Navigator>, navigator paths would usually be specified by a developer and should (hopefully?) not be so complex to require this level of handling. Although again noting that the underlying implementation is not revised here and it would continue to behave correctly in a real browser.

Testing Instructions

Verify that unit tests continue to pass.