Fix: Vitest, the "window.getComputedStyle" error is not defined when running tests

[ajivanyandev]

No description provided.

[Copilot]

Pull request overview

This PR fixes a Vitest compatibility issue where window.getComputedStyle errors are not handled gracefully in the readThemeMarker function. The fix adds a catch block to return null when getComputedStyle throws an error, preventing test failures in environments like Vitest where this method may not be fully implemented.

Key Changes:

• Added error handling to readThemeMarker() function in themes.ts to catch and handle getComputedStyle errors
• Added test coverage for the new error handling behavior

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
packages/devextreme/js/__internal/ui/themes.ts	Added catch block to readThemeMarker() to gracefully handle getComputedStyle errors by returning null
packages/devextreme/testing/tests/DevExpress.ui/themes.tests.js	Added two new tests to verify error handling when getComputedStyle throws errors

[VasilyStrelyaev]

I'm not sure I like this fix.

First, are we saying that it's normal that under vitest the window.getComputedStyles method is not mocked? Assuming we are in jsdom here, I can see it is in fact mocked:
https://github.com/jsdom/jsdom/blob/main/lib/jsdom/browser/Window.js#L908

and probably that's why this bug is not reproduced on macOS (and even on Parallels' Windows for ARM).

What's different on Windows x64?

And even if we think that it's too expensive to investigate this (do we?), okay, in this case we may want to support the case when there is no getComputedStyles in our environment. But is it a good way to do this with a blanket catch? Not checking for specific condition?

[ajivanyandev]

Thanks! Let me investigate a little more, and come back

[ajivanyandev]

Thanks! Let me investigate a little more, and come back

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

The fix only checks if window.getComputedStyle exists, but the tests expect the function to handle cases where getComputedStyle throws an error when called. The current implementation will still throw an error if getComputedStyle exists but throws when invoked. To properly handle this scenario, wrap the window.getComputedStyle call in a try-catch block within the existing try-finally structure.

Suggested change

	result = window.getComputedStyle(element.get(0)).fontFamily;
	let computedStyle;
	try {
	computedStyle = window.getComputedStyle(element.get(0));
	} catch (e) {
	return null;
	}
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	result = computedStyle && computedStyle.fontFamily;