Fix null window case in _getCurrentInfoManager()

[bancer]

Purpose

This is a fix for an issue reported in DevExpress/testcafe#7886. You can find the stacktrace there.

Approach

I do not know if this is the correct approach but it is logical and it fixes the problem. I tested it by editing hammerhead.js directly in our vendor folder.
The reasoning: The use case here is when contextWindow value is undefined what makes no need to call getSandboxBackup(). getSandboxBackup() aka get() called at the bottom of _getCurrentInfoManager() function may return null according to

testcafe-hammerhead/src/client/sandbox/backup.ts

Lines 44 to 56 in 6607246

	export function get (window: Window) {
	const topSameDomainWindow = getTopSameDomainWindow(window);
	const storage = topSameDomainWindow[SANDBOX_BACKUP];
	const iframe = window !== topSameDomainWindow ? window.frameElement : null;
	if (storage) {
	const record = findRecord(storage, iframe);
	return record ? record.sandbox : null;
	}
	return null;
	}

but null case was not processed in _getCurrentInfoManager(). So I assume that if it is okay for getSandboxBackup() to return null then it should also be okay for _getCurrentInfoManager() to return null.

I cannot add unit tests as my knowledge of hammerhead is very limited.

Debug for the context:

References

DevExpress/testcafe#7886

Pre-Merge TODO

• Write tests for your proposed changes
• Make sure that existing tests do not fail

[miherlosev]

Hi @bancer,

Thank you for this information. This behavior is incorrect. The contextWindow should not be equal to null. However, we cannot accept your PR. It's difficult to determine the cause of this behavior without a simple example. Please share a sample project that illustrates the behavior.

[bancer]

Should that be something like this then?

        if (!contextWindow) {
            throw new Error('Context window is undefined');
        }

[miherlosev]

Should that be something like this then?

No. We need to fix the flow that leads to the contextWindow === null situation. This is why we need a reproducible example.

[andrzej-woof]

@miherlosev I believe I can get you a way to reproduce it. Navigating to this URL in testcafe with native automation seems to cause same exception https://react-dropzone.js.org/#section-basic-example

[ayemelyanenko-chegg]

Sorry to chime in but does the testcafe log help in reproducing?

https://upload.disroot.org/r/1x3h34w8#bdMOCO33y7ltfgPrMsgsN9EyQcDBqSfc2pBzA6FApbk=

[miherlosev]

@ayemelyanenko-chegg

Thank you for the information. I already have an example to reproduce this behavior. See the latest updates at DevExpress/testcafe#7886.