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?
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?
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:
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.