Component without content policy gets style from previous component with policy

[HitmanInWis]

If I call io.wcm.testing.mock.aem.context.AemContextImpl#contentPolicyMapping with resourceType A, and then later in my test I construct a model of resourceType B that does not have a content policy, the currentStyle script variable for model B is injected with the style policy I set for resourceType A.

I ran the debugger and here's what I can see happening. In io.wcm.testing.mock.aem.context.MockAemSlingBindings#getStyle we have the following code:

            ContentPolicy contentPolicy = getCurrentContentPolicy(request);
            if (contentPolicy != null) {
                return new ContentPolicyStyle(contentPolicy, wcmComponentContext.getCell());
            }

            Design currentDesign = getCurrentDesign(request);
            if (currentDesign != null) {
                return currentDesign.getStyle(wcmComponentContext.getCell());
            }

What happens is the ContentPolicy for resourceType B ends up null (correctly) and the code falls back to currentDesign, which then calls currentDesign.getStyle(wcmComponentContext.getCell());

Inside of io.wcm.testing.mock.aem.MockDesign#getStyle(Cell) we have the following code:

        if (cell instanceof MockCell) {
            Resource resource = ((MockCell)cell).getComponentContext().getResource();
            return this.getStyle(resource);
        } else {
            return this.emptyStyle;
        }

cell is indeed an instance of MockCell, and the resource evaluates to my resource of resourceType A, which then causes the Style for resourceType A to be returned.

[HitmanInWis]

In case it's relevant, my resource of type B is at a child path of my resource of type A

/content/parent of type A
/content/parent/child of type B

When creating the model for /content/parent/child I'm getting the currentStyle of type A

[stefanseifert]

hmm ... this Design/getCurrentDesign code is there for backward compatibility for the very old CQ times (before template editor). maybe it's not fully correct. does the problem only occur for two resource types with a parent/child relation as you described?

can you come up with a PR with a test case that reproduces the problem?

[HitmanInWis]

Playing around with it a bit more, it appears that the issue only happens if the context.currentResource() is pointed at the resource of type A. If I change the current resource then it seems the design fallback doesn't get the style of resourceType A.

[stefanseifert]

i'm wondering if this use case behaves differently in a real AEM instance? afaik the currentStyle is always created from current request resource, and cannot "know" of a different resource type used in custom code to create a model using a different resource type than that of the current resource.

on the other hand there seems to be a change in AEM behavior related to this fallback to the old "design" mechanisms:
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/maintenance/2024/2024-3-0
SITES-8769 - Improve StyleImpl performance
but i think this is behind a feature toggle and not active by default.

[HitmanInWis]

currentStyle is indeed coming from the request resource. The issue is that when I create a sling model from my resource of resourceType B, currentStyle is (correctly) null, but that triggers the design fallback, and the design fallback seems to be linked to the context.currentResource().

if context.currentResource() is pointing to my resource of type A, then the design fallback gives me the MockStyle from type A in my model for type B
if context.currentResource() is pointing anywhere else, then the design fallback doesn't find a style, and I correctly get a null style in my model for type B

[stefanseifert]

can you come up with a PR containing a test case the reproduces the problem?

[HitmanInWis]

I wish I could spend the time, but unfortunately I cannot. I was able to work around the issue by ensuring my context.currentResource was set to a different resource.

If this issue is simply "yep, it's an issue, but no one has time to fix so we're going to close" I understand.