@erickok Did you have time to look at this MR? Are the changes ok like this?

It's okay, but I wonder what we can do to prevent the more and more constructor parameters from getting out of hand... Especially since now you have to keep passing this on to where you eventually want to use it. it's not so bad, but I'm just thinking out loud.

Yes, you're right. So there can be more and more parameters and at some point it becomes too much. But here it is more important that functionality is available. Otherwise I would have to create a custom renderer for each WebView.

Another idea would be to group the constructor parameters. Then there would be for example an iFrameConfig object.

Yes I agree, in this end we want to use this library. I hope to have some time very soon to dive into the code, as for now I am just trying to answer questions, clean up issues and give my review/opinion. Without counter argument soon, your pr should be merged.

I have tested this and it is working well. For example, I used in the example app:

          navigationDelegateForIframe: (request) {
            if (request.isForMainFrame && !Uri.parse(request.url).host.endsWith("google.com")) {
              return NavigationDecision.prevent;
            } else {
              return NavigationDecision.navigate;
            }
          },

and it prevents any navigation away from Google itself. (This is often used to start an external browser in such cases, to 'escape' the iframe.)

This is good to merge for me! @ryan-berger