Remove window.loadExtensionView.

[dompuiu]

Description

Remove window.loadExtensionView from sandbox.

Motivation and Context

There are better ways to test the extension views.

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[brenthosie]

What's the catalyst behind this change and will it unexpectedly introduce problems for customers relying on it?

[dompuiu]

@Aaronius Would you be kind and review this change? It's related to the last email you sent to us where you said you no longer need it.

[Aaronius]

Looks good. To answer @brenthosie's question, I initially added this functionality because I thought it was a good way for extension developers to be able to test their extensions in an automated fashion using something like TestCafe and Cypress. We thought we needed this for the web SDK extension and we actually used it for a couple years, but recently devised a better approach that doesn't require us to use the sandbox by mocking the extension bridge coming from Akamai. It simplified code and sped up the tests as well, so I would advise anyone else to take a similar approach instead of using this loadExtensionView functionality.

I don't know if anyone else is using this functionality currently, but if they are, then this removal will force them to use a different approach. As such, this should be released as a major version.

[Aaronius]

For reference, here's what we ended up doing instead. When running functional tests, our extension requests the extension bridge from Akamai and we return a mock extension bridge file instead that allows our functional tests to call the extension's init, getSettings, and validate methods as though it were Launch. We're leveraging network mocking capabilities built into TestCafe, though other frameworks have similar functionality. Here's the mock extension bridge file we use in place of the real extension bridge. This allows us to not have to run the extension within reactor-sandbox or even an iframe when running functional tests, while still being able to test the init, getSettings, and validate logic of the extension. If any other extension developers run into the same need, you could point them to this approach.