Thank you for your response. I'll have to get a little more updated, custom HTML fields might solve some of my concerns about creating custom UI components.

Do you know of/are there plans to allow loading module type scripts into the sandbox? Right now the Forms Designer UI doesn't permit it and trying to do it with an import() function is blocked by CORS. ...Maybe if my server permitted serving all domains, but I'm not about to do that.

Could you tell me (or refer me) more about the security tests? I can understand a concern about protecting against Forms process designers potentially introducing malicious scripts through incompetence/negligence, but the sandbox alone doesn't really prevent that, does it? A malicious script inside the sandbox could still access user input on the form, for example.

One final thought, do you have tips on speeding up the process of writing custom script with the new forms designer? I used to draft a lot of code in the devtools console and copy snippets over into my script. That technique doesn't work so well anymore now that the contexts are so different.

Again, thanks for your reply.

I also use a pair of iframe resizer scripts which go on a form and a website which embeds the LF form. I know Forms has an embed script which is supposed to be able to automatically resize the iframe containing the form, but it does it by reading the properties of the Forms document and fails due to CORS issues, so the autoheight setting doesn't work.

The scripts we are using on classic designer forms works by posting a message from the Forms document to the parent document, which in turn resizes the iframe according to the message instructions. We won't be able to use our custom scripts with modern designer since the one on the form has to be at the top level of the document, but if you guys updated your embedding script so that autoheight worked on webpages that are cross domain, then that's one big use case taken care of.

Do you know of/are there plans to allow loading module type scripts into the sandbox? 

Typically in this scenario the script is allowed from any origin, but for a couple of reasons I want to see if we can apply a specific origin to the sandbox for CORS security checks without specifically allowing all domains. Many 3rd party APIs restrict calls to specific origins so this would alleviate both issues.

Could you tell me (or refer me) more about the security tests? I can understand a concern about protecting against Forms process designers potentially introducing malicious scripts through incompetence/negligence, but the sandbox alone doesn't really prevent that, does it? 

In this scenario we're mostly trying to isolate the users credentials from designer scripts and malicious 3rd party scripts/extensions. I'll try to locate more specifics when I get a chance.

One final thought, do you have tips on speeding up the process of writing custom script with the new forms designer?

I write almost all of my code in VSCode using a typings file I made myself. I do plan to release this a community downloadable typings file for local development. For your use case, in the devtools window you can toggle the frame source to the sandbox window and this will give you access to the LFForm object and sandbox scope. There is a context for each extension loaded on the page but the sandbox should be the very last one in the list. Note, if you select any element on the page from the Elements tab it will reset this context back to the main page so you'll need to toggle it back in that case.

I also use a pair of iframe resizer scripts which go on a form and a website which embeds the LF form.

I'm unfamiliar with this script, but this could be something we bake into the new designer automatically. Any time I've used iframes I have been able to control it from the origin without needing to worry about the content being loaded into the iframe. The new designer should render fine at any dynamic width/height (current min width is 400px but we're removing that)