WebHTMLViewer.UseSandbox

The language reference simply says:

If True, sandboxes the page in the WebHTMLViewer from being able to access the web application in which it is used.

Can anybody please make this a little more verbose so perhaps I can understand what it means?

For CEF, click here: Sandbox

This isn’t chromium. Sandbox is something that’s added to the iframe tag/construct which is created when you use LoadURL on WebHTMLViewer.

For more info see:

https://www.w3schools.com/tags/att_iframe_sandbox.asp

So @Greg_O_Lone is the LR correct in this terminology ? Even if this property is not set, there is no actual way for the code within the viewer to access the web application right ?

Short of using the handleURL ‘route’ through some JS on the page in the viewer and identifying the relevant session (if that’s what one is looking for (I am)) ?

Sure you can, through javascript. If the iframe is t sandboxed, you can use “window.parent” to access the window object of the containing view… assuming there aren’t other restrictions in place in the users browser.

Just do a search on the web for iframe and JavaScript and I’m sure you’ll find examples on how to do that.

Thanks but maybe I’m being too literal with my interpretation - it says access the web application - as opposed to the client side containing view.

Maybe my use-case would be better - I’d like to display an arbitrary page ‘within’ a web app page and have that page communicate with the web app - i.e. the server, in any number of ways (take for example a click on an element on the page within the iframe). So to get this event back to the server code, I’d need to do what ? Inject a JS click handler piece of code into the parent which, when called, executes ‘executeserverevent’ or the Web 2.0 equivalent ?

Yes. And you can do that with the WebSDK.

Oh, I see, not a switch for the HTMLViewer engine sandbox (yes, I missed that we were talking about the “web” variant), So it just adds the iframe sandbox attribute and let the able browsers do its jobs.

But that’s the point - I’ve developed enough of them. Looking for something more dynamic.

And now I understand what is meant, I’ll reconfirm that the LR is mis-worded IMO.

You could pretty easily create a bridge that would let you send a JSON string back to the app. Then your Xojo code could decide based on a particular key as to what it’s supposed to do with the data.

Thanks @Greg_O_Lone that’s the tyoe of thing I’m exploring. What would be the mechanics of that ? Using a WebSDK control as the bridge and getting the msg back that way ?

Or maybe hitting /api with a payload including a session identifier ?

Either way. I like using the WebSDK myself which would be a Non-UI Xojo control and it’s JavaScript counterpart which just sends commands to the server.

Thanks @Greg_O_Lone I like the WebSDK route so as to remain within the session context.

What would be the JS calling convention to call a method on the custom control ? Assume it is namespaced with a convention (I am on Web 1.0 btw) ?

There’s a WebSDK pdf in the extras folder that explains how to do this.

Thanks @Greg_O_Lone I am experimenting now.