Add ability to receive a message from the web page context.

[samir-mahendra]

There are times where we need the Javascript running in the context of a web-page to send a signal to the remote process.

PhantomJS has this feature: http://phantomjs.org/api/webpage/handler/on-callback.html

This is currently possible by having the web application call: "console.log('expected event')", and then checked for the message received using the "Runtime.consoleAPICalled" event, but that seems a bit hacky.

[dgozman]

Does Runtime.awaitPromise (or awaitPromise flag in Runtime.evaluate) help?

[dgozman]

@aslushnikov who was hitting the same

[samir-mahendra]

awaitPromise helps in situations where the controlling process knows to expect a signal from the web context at some later time, and it's true that this handles most of the use cases PhantomJS's onCallback was used for.

Here's a use case where it won't work for us:

One application we are testing is a non-single page app, and has a page that, after on load, runs about 30K lines of Javascript (dynamically generated by server, so # of lines varies) in the HTML body before it's "ready" to check it's DOM. We initially handled testing it by waiting for the load Event and then timing out, but then under load test conditions, with the CPU pegged, the timeout was firing too early.

This application is being tested through a re-writing proxy, so in the proxy, we added a call to "callPhantom" after the last line of Javascript, like so:

// Existing JS
window.top.callPhantom({event: "readytotest"});
</script>

In PhantomJS, we then get a onCallback that tells us in a deterministic way that the page is loaded.

We're looking for something similar for Headless Chrome without using a 'console.log' and looking for it with a 'Runtime.consoleAPICalled' callback.

[dgozman]

I think this particular usecase can be covered by awaiting promise: Runtime.evaluate({ expression: 'new Promise(fulfill => window.callPhantom = fulfill)', awaitPromise: true, returnByValue: true}) This will return {result: {event: 'readytotest'}}. Am I missing something? - Dmitry

…

On Thu, Apr 27, 2017 at 6:57 AM, Samir Mahendra ***@***.***> wrote: awaitPromise helps in situations where the controlling process knows to expect a signal from the web context at some later time, and it's true that this handles most of the use cases PhantomJS's onCallback was used for. Here's a use case where it won't work for us: One application we are testing is a non-single page app, and has a page that, after on load, runs about 30K lines of Javascript (dynamically generated by server, so # of lines varies) in the HTML body before it's "ready" to check it's DOM. We initially handled testing it by waiting for the load Event and then timing out, but then under load test conditions, with the CPU pegged, the timeout was firing too early. This application is being tested through a re-writing proxy, so in the proxy, we added a call to "callPhantom" after the last line of Javascript, like so: // Existing JS window.top.callPhantom({event: "readytotest"}); </script> In PhantomJS, we then get a onCallback that tells us in a deterministic way that the page is loaded. We're looking for something similar for Headless Chrome without using a 'console.log' and looking for it with a 'Runtime.consoleAPICalled' callback. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJbHWmtO1U9yoV_w1RwD42uEYsEk5aquks5r0J7egaJpZM4NIBPo> .

[pavelfeldman]

awaitPromise can be only used once, while it might be handy to be able to call something repeatedly. I would say that using console.debug is the most pragmatic approach to address it atm.

[kensoh]

Hi @samir-mahendra I'm also using headless Chrome for web automation. At the moment I try to check for some changes in DOM as an indication that the script or some activity that is supposed to be done is ready.

It is probably not an elegant way to do it this way, but it closely resembles a user's behaviour when using the browser (click something, wait for something to visually appear, then do something else). So I use that approach.

[mmuffins]

Considering that the last message in this issue was written over a year ago - does anybody know if there were any updates related to this question?

I have a very similar use case where I want to react to a custom event, and the suggested workaround to inject some javascript that calls console.debug whenever the event is fired and listen to runtime.consoleAPICalled still seems like the best (and only) approach to do so, but it really feels more like a hack than a proper solution.

[alexkozy]

You may consider using Runtime.addBinding. As soon as binding called you will get Runtime.bindingCalled notification with string paylod.

[mmuffins]

I'll have a look at that, thanks a lot!

[TimvdLippe]

This repository is related to Chrome DevTools Protocol, but does not track issues regarding its definition or implementation. If you want to file an issue for the Chrome DevTools Protocol, please open an issue on https://crbug.com under component: Platform>DevTools>Platform. Thanks in advance!