test(integration-karma): add a new FORCED_MIXED_SHADOW_MODE

[rui-rayqiu]

Details

Add a "FORCED_MIXED_SHADOW_MODE" to integration-karma so that tests run in native shadow mode while applying synthetic shadow polyfill.

Does this PR introduce breaking changes?

• ✅ No, it does not introduce breaking changes.

If yes, please describe the impact and migration path for existing applications.

The PR fulfills these requirements:

• Have tests for the proposed changes been added? ✅
• Have you followed these instructions to clearly describe the issue being fixed or feature enhanced? ✅

GUS work item

W-9726385

[nolanlawson]

Reading through W-9726385, I thought that the goal was to run LWC in native mode, but in such a way that it wasn't aware of synthetic shadow DOM? It looks like this PR is force-opting components into native mode when synthetic shadow is loaded, but LWC is still aware of synthetic shadow and is just not using it.

These two scenarios are both valid to test, but I'm not sure what we were trying to test here. /cc @ekashida Am I misreading this?

[ekashida]

To be extra sure this never makes it into prod, I'd add an additional guard here. Also suggest we make name the name more explicit.

Suggested change

	// Forced mixed shadow mode for testing
	if (process.env.FORCED_MIXED_SHADOW_MODE) {
	if (process.env.NODE_ENV !== 'production') {
	if (process.env.FORCE_NATIVE_SHADOW_MODE_FOR_TEST) {

[rui-rayqiu]

I already put it inside a if (process.env.NODE_ENV !== 'production') (Line 315). I can change the name to be more explicit.

[ekashida]

@nolanlawson Sorry, didn't see your comments.

Reading through W-9726385, I thought that the goal was to run LWC in native mode, but in such a way that it wasn't aware of synthetic shadow DOM?

That sounds like a very subtle distinction. Could you explain the difference?

[nolanlawson]

@ekashida

That sounds like a very subtle distinction. Could you explain the difference?

1. This PR: Acts as if all components have static shadowSupportMode = "any", runs with @lwc/synthetic-shadow loaded.
2. The experiment I ran earlier: loads @lwc/synthetic-shadow, but with string replacement (e.g. here) so that @lwc/engine-dom doesn't realize synthetic shadow is loaded. Instead, the LWC engine acts is if everything is pure native shadow. This reveals bugs in the synthetic shadow implementation.

With # 2, we could run it in our CI, but plenty of the tests would fail because of synthetic shadow bugs. Maybe it's not practical to test for the moment.

[rui-rayqiu]

@nolanlawson In mixed shadow mode RFC, it says "A third testing mode will be introduced for mixed shadow mode. This test environment will ensure that components running in native mode will work correctly even when synthetic Shadow DOM polyfills are present." So I think this way it would be the third testing mode.

I may be understanding it incorrectly but wouldn't # 1 and # 2 in your comment have same effects? Is "LWC engine acts as if everything is pure native shadow" equivalent to lwc operates in native shadow mode? Or would LWC engine operates differently in native mode when it realizes that synthetic shadow is loaded?

[nolanlawson]

@rui-rayqiu

ensure that components running in native mode will work correctly even when synthetic Shadow DOM polyfills are present

This makes sense to me! I think this PR is valid; I was just trying to understand what the goal is.

I may be understanding it incorrectly but wouldn't # 1 and # 2 in your comment have same effects?

No, because in # 1, LWC understands that synthetic shadow is present. When it wants to render in native mode, it passes in a special KEY__SYNTHETIC_MODE option:

lwc/packages/@lwc/engine-core/src/framework/base-lightning-element.ts

Lines 243 to 247 in bca4d26

	const cmpRoot = renderer.attachShadow(elm, {
	[KEY__SYNTHETIC_MODE]: shadowMode === ShadowMode.Synthetic,
	delegatesFocus: Boolean(ctor.delegatesFocus),
	mode,
	} as any);

...which synthetic shadow uses to understand that it should call the actual native attachShadow:

lwc/packages/@lwc/synthetic-shadow/src/faux-shadow/element.ts

Lines 79 to 82 in bca4d26

	if ((options as any)[KEY__SYNTHETIC_MODE]) {
	return attachShadow(this, options);
	}
	return originalAttachShadow.call(this, options);

Whereas in # 2, the communication link between synthetic shadow and engine-dom is broken. So LWC believes it's operating on top of native shadow, but in fact it's operating on top of synthetic shadow. This reveals the kind of bugs that may occur if, for instance, LWC is combined with another shadow-DOM-using framework on the same page, and synthetic shadow DOM is present.

[rui-rayqiu]

@rui-rayqiu

ensure that components running in native mode will work correctly even when synthetic Shadow DOM polyfills are present

This makes sense to me! I think this PR is valid; I was just trying to understand what the goal is.

I may be understanding it incorrectly but wouldn't # 1 and # 2 in your comment have same effects?

No, because in # 1, LWC understands that synthetic shadow is present. When it wants to render in native mode, it passes in a special KEY__SYNTHETIC_MODE option:

lwc/packages/@lwc/engine-core/src/framework/base-lightning-element.ts

Lines 243 to 247 in bca4d26

	const cmpRoot = renderer.attachShadow(elm, {
	[KEY__SYNTHETIC_MODE]: shadowMode === ShadowMode.Synthetic,
	delegatesFocus: Boolean(ctor.delegatesFocus),
	mode,
	} as any);

...which synthetic shadow uses to understand that it should call the actual native attachShadow:

lwc/packages/@lwc/synthetic-shadow/src/faux-shadow/element.ts

Lines 79 to 82 in bca4d26

	if ((options as any)[KEY__SYNTHETIC_MODE]) {
	return attachShadow(this, options);
	}
	return originalAttachShadow.call(this, options);

Whereas in # 2, the communication link between synthetic shadow and engine-dom is broken. So LWC believes it's operating on top of native shadow, but in fact it's operating on top of synthetic shadow. This reveals the kind of bugs that may occur if, for instance, LWC is combined with another shadow-DOM-using framework on the same page, and synthetic shadow DOM is present.

@nolanlawson Thanks for the detailed explanation! That makes sense.