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'm actually using webview for automation instead of creating an interactable custom webpage so I found the ExecuteScriptAsync feature useful on the Windows Webview. Except I was trying to port my code to a Raspberry Pi and Webview currently doesn't work on Linux.
Given the code segment above, I think it might be possible to reproduce that behavior here if we could directly inject a custom javascript string instead of searching for a pre-registered function. I.e. skip the GetInvokeScript step and the ResolveEventResult step and just return resultJson directly.
Is this not done because the intent of the bridge was to work with well-defined endpoints? Or is it because calling ExecuteScriptAsync directly is inherently unstable and creates all sorts of unpredictable side effects? Did I happen to miss a function that actually does what I'm requesting already?
Bear in mind that I don't control the endpoint, so I can't insert custom code into the destination webpage. And I'm not desperate enough to encapsulate the endpoint into an iFrame just so I can embed tools in the parent container to manipulate whatever's in the iFrame.
That being said, here's an example of my code when I directly used Webview2.
There is an interesting segment of code in SpiderEye.Bridge.WebviewBridge:
I'm actually using webview for automation instead of creating an interactable custom webpage so I found the ExecuteScriptAsync feature useful on the Windows Webview. Except I was trying to port my code to a Raspberry Pi and Webview currently doesn't work on Linux.
Given the code segment above, I think it might be possible to reproduce that behavior here if we could directly inject a custom javascript string instead of searching for a pre-registered function. I.e. skip the GetInvokeScript step and the ResolveEventResult step and just return resultJson directly.
Is this not done because the intent of the bridge was to work with well-defined endpoints? Or is it because calling ExecuteScriptAsync directly is inherently unstable and creates all sorts of unpredictable side effects? Did I happen to miss a function that actually does what I'm requesting already?
Bear in mind that I don't control the endpoint, so I can't insert custom code into the destination webpage. And I'm not desperate enough to encapsulate the endpoint into an iFrame just so I can embed tools in the parent container to manipulate whatever's in the iFrame.
That being said, here's an example of my code when I directly used Webview2.
Set a user, set a password, then click a specific button. Wait for page loaded event to execute further actions.
The text was updated successfully, but these errors were encountered: