Add ability to receive a message from the web page context. about devtools-protocol HOT 10 CLOSED

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.

from devtools-protocol.

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

from devtools-protocol.

@aslushnikov who was hitting the same

from devtools-protocol.

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.

from devtools-protocol.

from devtools-protocol.

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.

from devtools-protocol.

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.

from devtools-protocol.

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

from devtools-protocol.

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

from devtools-protocol.

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!

from devtools-protocol.