Retrieving page HTML synchronously

[emerick]

The CEF wiki mentions that "In rare cases it may be necessary to implement synchronous communication between the browser and render processes." I'm unfortunately facing one of those cases at the moment. My ultimate goal is to call CefFrame::GetSource (or an equivalent JavaScript function to retrieve the source) in a fully synchronous manner. It would be quite (quite) a vast undertaking to make this portion of our legacy app asynchronous, so I'm hoping that I can somehow leverage the technique outlined on the wiki which references using a synchronous XMLHttpRequest and a native scheme handler. However, I'm not sure if that's at odds with what I'm trying to achieve as far as retrieving the underlying HTML. Could anyone point me in the right direction here?

[magreenblatt]

What are you trying to accomplish? If you need to access/modify HTML as it arrives over the network you might consider filtering using CefRequestHandler::GetResourceResponseFilter.

[emerick]

My application provides a rich-text editor using a contentEditable frame. At various points, I need to save the underlying HTML source code (for example, when the user switches documents or saves). My problem is that for a lot of architectural reasons, it's proven extremely difficult to make that work in an asynchronous manner (this is a long-lived legacy application). I'm wondering if there's some (any!) potential way forward.

[fddima]

@emerick custom communication channel implies to work in parallel to standard communication channel, and gives you ability to do remote execution in any fashion (sync/async). But don't let fool self: "server" at renderer side most likely accept messages on separate thread, and now you will need to solve same synchronization problem: we executes on one thread, but want to do job on another thread (usually on renderer thread). So post message & wait can help (I'm leaving v8 context tricks aside.) From client perspective you anyway need post message to custom communication channel & wait.

So, as you see (at client side): you anyway need send something & wait. The only difference that blocking of any CEF threads will not block custom communication channel. But problem & actions are exactly same.

So, i'm more likely to turn question in other direction:

1. If you job (in browser process) executed on own thread (non CEF) then you can safely post message & wait.

2. If you job executed on CEF thread for some reason - then you there need true asynchronous code (may be based on continuations).

I'm think that it should be much easier to use (1) or (2) just because you not need in complex custom channel machinery: i'm believe custom channel will be much harder than dispatch your jobs onto separate threads and wait (async) results.

I.e. from my understanding: you not need true synchronous access, you only need sync fashioned calls => to utilize CEF-provided IPC you should not block CEF threads => you job should executed on non-CEF thread to able wait result. This is still too hard to implement?

[magreenblatt]

My application provides a rich-text editor using a contentEditable frame. At various points, I need to save the underlying HTML source code (for example, when the user switches documents or saves). My problem is that for a lot of architectural reasons, it's proven extremely difficult to make that work in an asynchronous manner (this is a long-lived legacy application). I'm wondering if there's some (any!) potential way forward.

What specifically is the problem with async saving? Take a snapshot of the contentEditable contents when the user clicks "save" and send to the browser process via XMLHttpRequest. If the user navigates away by clicking a link or button then delay that navigation (use onclick JS instead of href links) until the save completes.

[emerick]

I.e. from my understanding: you not need true synchronous access, you only need sync fashioned calls => to utilize CEF-provided IPC you should not block CEF threads => you job should executed on non-CEF thread to able wait result. This is still too hard to implement?

Right, I see exactly what you're saying. That approach makes a ton of sense, thanks for pointing it out (seems obvious now, of course!)