iframe in replpad-js

Domains Web
1

I was thinking about using rebol to automate some tasks on web applications have to use regularly. Obviously, replpad-js can leverage the browser (which can take care of cookies, etc.). I want the IFRAME to be resizable and I do not want to use any JS for that.

inline-css: function [
    {Provide default CSS for resizing inline frame}
][
    css-do {.replpad-resizer { display:flex; margin:0; padding:0; resize:both; overflow:hidden }
            .replpad-resizer > .replpad-resized { flex-grow:1; margin:0; padding:0; border:0 }
            .replpad-border { background:gray; border:1px dashed black; }}
]

The inline function takes the URL and an id and inserts the IFRAME (maybe it should use the original URL as the id?).

inline: function [
    {Provide a browsing context in the replpad}
    url [url!]
    name [text!]
][
    replpad-write/html unspaced [
        <div class="replpad-resizer replpad-border">
        {<iframe class="replpad-resized" src="} url {" id="} name {"></iframe>}
        </div>
    ]
]
1 Like
2

Aren't you going to be bitten by CORS?

3

So far I have used it with one Moodle site and had no issues with it. I imagine that as long as I trigger the inlined web page to generate the requests it should be fine, but I still have to try it out.

4

Cool that you were able to look through it and make something work!

If you're interested in automation of the browser by code in the browser...something that is on the horizon being looked into is driving the browser from a native executable using the Chrome DevTools protocol.

https://chromedevtools.github.io/devtools-protocol/

It's worth the time--if you haven't already tried it--to kick off the test they suggest running two browser sessions:

The Developer Tools front-end can attach to a remotely running Chrome instance for debugging. For this scenario to work, you should start your host Chrome instance with the remote-debugging-port command line switch:

chrome.exe --remote-debugging-port=9222

Then you can start a separate client Chrome instance, using a distinct user profile:

chrome.exe --user-data-dir=<some directory>

Now you can navigate to the given port from your client and attach to any of the discovered tabs for debugging: http://localhost:9222

I'd like to be able to speak websockets and communicate with the browser:

  • to control it from a desktop Ren-C .EXE for testing, and replace things like this Python script that makes sure the web build runs in a headless browser

  • to give a backchannel to the web build for controlling the browser as a user would, by asking the desktop Ren-C to do its bidding

  • to inform the design of remote debugging by having the desktop .EXE probe the WASM build

I've done some basic experimentation with libwebsockets just to see what it takes to link them in as a first try. I think we'd want to ultimately implement the websocket protocol in usermode vs. a big stack of opaque C...but it could get the process started.

1 Like
5

Making more progress using your approach?

6

I haven't done any more experiments in this direction. I thought about it some more and I an now leaning towards using Moodle's REST API directly (once I figure out how to get the web services token...)...

7

@rgchris has a REST module I believe.

8

I had found that, but what I have to wrap my mind around first is how to sign on. The Moodle installation I want to talk to uses SSO with a Shibboleth identity provider. I am aware there is ECP and that's what I need to look into next.