Using AEM XFs in Adobe Target

[jezwn]

I've two XFs in AEM which has been exported to Adobe Target and is being used in the AB activities. The XFs are basically formstack(third party) forms where the content is form HTML(not embed code). The form is getting loaded correctly in the pages. When previewing the QA URL couple of uncaught errors are shown in the console and it is hindering the form submission.
Debugging the console errors, it was observed that some of the scripts(loaded using <script src="scriptUrl"></script>) appears to be not getting loaded in the page resulting in the console errors. 
Interestingly, when I add the form HTML directly in the AB experience instead of adding it as an XF, everything works smoothly without any concerns.

Any thoughts?

More details:

In our particular scenario, we have noticed that when the form HTML is added directly from the target, no issues arise. However, when it is added via the Experience fragment, console errors are observed and is hindering form submission. Several console errors are generated, indicating "Mixed Content: The page at 'URL' was loaded over HTTPS, but requested an insecure stylesheet 'URL'. This request has been blocked; the content must be served over HTTPS."

Assumption:

Based on this observation, we suspect that there might be HTTP calls originating from the Experience fragment causing the experiences to not load correctly hindering the form submission. However, upon evaluating the source of the Experience fragment, we did not identify any HTTP URLs. This suggests that there may be nested calls within the CSS/JS files, which in turn invoke other files or packages via HTTP.

Is it possible that the http calls are causing this issue?

[EstebanBustamante]

Sounds like the script tag maybe not rendering due to security concerns.

The first thing to check is if the HTL context is correct, I would recommend discarding that possibility by setting context="unsafe" in a lower environment and just for troubleshooting purposes. 

[jezwn]

I've an update here:

In our particular scenario, we have noticed that when the form HTML is added directly from the target, no issues arise. However, when it is added via the Experience fragment, console errors are observed and is hindering form submission. Several console errors are generated, indicating "Mixed Content: The page at 'URL' was loaded over HTTPS, but requested an insecure stylesheet 'URL'. This request has been blocked; the content must be served over HTTPS."

Assumption:

Based on this observation, we suspect that there might be HTTP calls originating from the Experience fragment causing the experiences to not load correctly hindering the form submission. However, upon evaluating the source of the Experience fragment, we did not identify any HTTP URLs. This suggests that there may be nested calls within the CSS/JS files, which in turn invoke other files or packages via HTTP.

Do you think the http calls could be causing this?

[EstebanBustamante]

Yeah, that seems to be the issue then, can you track who initiates the stack of those HTTP calls? You can do this by looking at the network tab in Chrome dev tools.

[kautuk_sahni]

@jezwn If you have successfully found a solution on your own, we kindly ask that you share it with the community for future reference and mark it as the correct answer.