You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've just found that the confirm() method is not supported by the PhantomJS driver on the Spiderling side. However, these things are supported by Phantom itself:
In this sort of closure, we'd have to call PhantomJS to set future expectations, rather than to click on it after it has appeared (since the callback will only be fired once, and it needs to be ready to return a value when it is called).
I would guess that if the closure returns null then that is like "no answer" and the dialogue remains. If that does not work, then perhaps there is some sort of error condition that can be set, so it can be detected on the PHP side.
Alternatively, this closure could contain a loop that waits for a post-appearance answer, though I don't know how that would affect PhantomJS.
I am not sure how much time I would have to help on this, but it is good to have it in the issue tracker. Would someone give their thoughts on how this could be implemented, and what would fit in with the general Spiderling approach?
The text was updated successfully, but these errors were encountered:
Just thinking out loud, but I wonder if it would be possible to access the current Page from the PHP side, in $page->execute()? If I could inject the onConfirm property from my test, that would be a quick workaround. Something like:
(As it is, I am using execute() to carry out the action after the confirm() dialogue is accepted. It effectively skips part of the UI, but that's acceptable for me).
I've just found that the
confirm()
method is not supported by the PhantomJS driver on the Spiderling side. However, these things are supported by Phantom itself:There's another ticket saying that PhantomJS does not support these things - my guess is that these things were added more recently.
It looks like the following code could be used in Spiderling's
phantom.js
to handle a confirm dialogue:In this sort of closure, we'd have to call PhantomJS to set future expectations, rather than to click on it after it has appeared (since the callback will only be fired once, and it needs to be ready to return a value when it is called).
I would guess that if the closure returns
null
then that is like "no answer" and the dialogue remains. If that does not work, then perhaps there is some sort of error condition that can be set, so it can be detected on the PHP side.Alternatively, this closure could contain a loop that waits for a post-appearance answer, though I don't know how that would affect PhantomJS.
I am not sure how much time I would have to help on this, but it is good to have it in the issue tracker. Would someone give their thoughts on how this could be implemented, and what would fit in with the general Spiderling approach?
The text was updated successfully, but these errors were encountered: