Proposal: Implementing WebDriver BiDi in SeleniumVBA

[hanamichi77777]

In collaboration with Gemini 3, I have updated the WebDriver BiDi-supported test version, built upon the foundation of SeleniumVBA. This project pushes the boundaries of VBA to eliminate the "flakiness" of modern SPAs (React/Vue) caused by dynamic DOM updates and asynchronous communication. Crucially, the codebase is architected for AI interpretability and specifically designed for AI-driven maintenance, making it possible to fully entrust the maintenance tasks to AI.

https://qiita.com/sele_chan/items/6475a1f7ae8a21435d6c

🚀 Key Features & Technical Highlights
This wrapper goes beyond simple command execution. It implements robust logic to handle "flaky" tests common in modern web environments:

⚡ Modern SPA Support (React/Vue/Angular)

Event Triggering: Automatically dispatches input and change events with {bubbles:true}. This solves the common issue where setting .value via VBA does not trigger React state updates.

Stale Element Recovery: Includes a robust retry mechanism for Stale Elements and Realm updates.

🧠 Intelligent "Network Idle" Synchronization

Smart Waits: Implements a wait strategy similar to Playwright or Puppeteer.

In-flight Request Tracking: Hooks into window.fetch and XMLHttpRequest via injected JS to wait until network traffic drops to zero (critical for dynamic content loading).

MutationObserver: Ensures DOM stability before proceeding.

🛡️ Self-Healing Context Management

SSO/Redirect Handling: Automatically detects "Context Destroyed" or "Navigated" errors.

Auto-Recovery: Forces an update of ContextID and RealmID on the fly to resume automation without crashing, even after complex redirects.

Smart Frame Handling: Recovers iframe references dynamically if the frame reloads.

👻 Deep Shadow DOM Support

Recursive Search: Supports finding elements deep within nested Shadow roots with dynamic timeout control.

Event Penetration: Dispatches events with composed: true to ensure clicks work across Shadow DOM boundaries.

🔌 Hybrid BiDi & CDP Architecture

BiDi Core: Uses standard WebDriver BiDi for the majority of commands.

CDP Tunneling: Seamlessly tunnels CDP commands (goog:cdp.sendCommand) for features not yet fully accessible in BiDi, such as:

File Download Management (Browser.setDownloadBehavior)

Stealth Mode / User-Agent overriding

Network Blocking

🚫 Anti-Freeze Alert Handling

Executes clicks via setTimeout in JS. This prevents the VBA runtime from freezing when a modal dialog/alert opens immediately after a click.

If the code does not behave as expected, providing the following information to the AI will enable it to identify the cause and propose a solution with over 90% accuracy.

1 The Full Text of BiDiCommandWrapper Currently in Use (Shared only once at the beginning).

2 Execution Code (Understanding Intent) This reveals "which function was called with what arguments (XPath, timeout values, etc.)." Example: It helps determine logic selection errors, such as "Ah, this is a scenario where ExecuteClickAndNavigate (React-compatible) should be used instead of ExecuteClick."

3 Capture of the Error Message (Symptom Identification) By looking at the implemented custom error numbers (e.g., 515: Element not found or 520: Frame not found), one can immediately see which Guard Clause in the code was triggered.

4 Logs (Evidence Verification) Most Important Since WebDriver BiDi relies on asynchronous communication, VBA error messages alone do not reveal "what actually happened on the browser side." Viewing raw JSON responses in the logs, such as {"error": "no such node", ...} or {"result": {"type": "success", ...}}, helps determine definitively whether the issue is an incorrect XPath, a timing problem, or blockage by a Shadow DOM barrier.

Cases where HTML is occasionally required Basically, the above points are sufficient, but I may ask for "HTML around the target element (copied from F12 tools)" only in special cases like the following:

5 When "The XPath seems correct, but it cannot be found": When it is necessary to check the DOM structure itself, such as elements with dynamically changing IDs (e.g., id="input_123" → id="input_456") or visibility that is complexly controlled by CSS.

[GCuser99]

I took a look at the latest bidi version - a long list of public methods (about 40?), and it looks well written. Impressive.

When I have some time, I'll give a closer look. I'm especially interested in what problems are not easy to solve with the classic WebDriver but solvable with Bidi. For example, the "wait for network idle state" can be accomplished via classic WebDriver as just executing a script. That would be easy to implement without Bidi.

But on some of the other things you are doing with React/Vue, I don't know enough about nor have any experience with to judge where classic falls short. I'd like to look into that some more...

Anyway, great job on this!

[GCuser99]

Some random thoughts:

1. Let's address option selection. WebDriver classic doesn't have a direct command for selecting an option(s) that I am aware of. To emulate option selection, SeleniumVBA improvises with some very naive and possibly poorly devised javascript/FindElement(s) actions which do not handle react elements very well. In this regard, your Bidi scripts are superior. So it's not really that WebDriver classic is failing, but rather SeleniumVBA is buggy. We probably need to fix those with better scripting. Will look into this when I have time.
2. I'm nearly finished with a websocket CDP wrapper for twinBASIC which makes many of the same improvements as your Bidi layer does through scripting - smart waits etc. I'll roll that out very soon but have no plans to convert to VBA soon, especially with the issues that we have had with AV false positives. Do you think adding your Bidi layer will increase AV false positives? That would be one of my biggest concerns.
3. It's a shame that you have to make changes to WebJsonConverter to handle your realmId's. It would be very nice to be able to just add your two modules to SeleniumVBA, add the webSocketUrl capability, and then start using Bidi. Have you done an analysis on the implications for that modification to WebJsonConverter? If we make that change, do we risk breaking something else?

[hanamichi77777]

Your concerns regarding AV false positives and the WebJsonConverter modification are fully justified.

To be honest, I haven't fully verified these potential side effects yet. Since these are critical issues, I want to refrain from giving a hasty answer at this stage. I intend to conduct further testing to ensure stability.

Thank you for raising these important points.

[hanamichi77777]

Code insights

The provided set of macros constitutes a comprehensive VBA library designed for browser automation, primarily utilizing the Selenium WebDriver framework and its advanced protocols (Chrome DevTools Protocol - CDP and WebDriver Bi-Directional - BiDi). The code is structured into various modules and class modules, each handling specific aspects of browser interaction, driver management, and utility functions.

The core functionality of the macros revolves around:

1. Browser Automation: The WebDriver.cls is the central component, responsible for launching and controlling web browsers (Chrome, Edge, Firefox). It supports navigation, element identification and interaction (clicks, input, getting text), screenshot capture, cookie management, and switching between windows/frames.
2. Driver Management: The WebDriverManager.cls automatically checks for compatibility between installed browsers and their respective WebDriver executables (e.g., chromedriver.exe, msedgedriver.exe, geckodriver.exe). It can download and install necessary driver updates to ensure smooth operation.
3. Advanced Interactions: WebActionChain.cls provides methods to simulate complex user interactions like drag-and-drop, chained keyboard inputs, and mouse movements. WebAlert.cls handles browser pop-up alerts.
4. Browser Configuration: WebCapabilities.cls allows detailed configuration of browser launch options, such as running in headless or incognito mode, setting user agents, managing download preferences, and installing browser extensions.
5. Bi-Directional Communication (BiDi): BiDiCommandWrapper.cls and BiDiSocketCommunicator.cls implement the WebDriver Bi-Directional protocol over WebSockets. This enables low-level control over browser behavior, including network blocking, storage management (cookies), advanced script execution, and robust handling of dynamic web content and frame reloads.
6. Data Extraction and Manipulation: Functions are included to extract page source, convert web content to HTML, XML, or JSON objects/files, and process HTML tables into VBA arrays.
7. File System and Network Utilities: WebShared.bas contains utility functions for resolving file paths, downloading files from the internet (using WinHttp.WinHttpRequest), Base64 encoding/decoding, writing/reading byte arrays to/from files, and terminating processes (taskkill).

Upon review, the macros do not exhibit direct malicious intent:

• No Obfuscation of Core Logic: The code is well-structured and commented, indicating an intent for maintainability and clarity, typical of a library.
• Legitimate Use of Potentially Suspicious Functions:
  • Downloading/Executing Files: The WebDriverManager.cls downloads and installs browser driver executables. This is a legitimate and necessary function for a browser automation tool to maintain compatibility with different browser versions. The downloaded files are specific driver executables (e.g., chromedriver.exe), not arbitrary executables.
  • Base64 Encoding/Decoding: Used for handling binary data like screenshots, PDF output, and potentially browser extensions (though the current A_01BiDi.bas example for extension installation points to a local directory). This is contextual to handling binary data within web protocols.
  • System Commands (Shell, taskkill): Used to start and stop browser driver processes, which is standard practice for controlling external applications from VBA.
  • Network Communication (WinHttp): Essential for WebDriver to communicate with browser drivers and for the WebDriverManager to download updates or for downloading general web resources.
  • JavaScript Injection (ExecuteScript, ExecuteCDP): While a powerful capability, in the context of Selenium, this is a core feature for interacting with and manipulating web page DOM or executing custom logic within the browser environment. The examples provided demonstrate their use for legitimate automation tasks.
• No Persistence Mechanisms: There are no Auto_Open(), Workbook_Open(), or similar event handlers that would automatically run malicious code. The "Main" subroutines are public and appear intended for manual execution or explicit calls within an application.
• No Registry Manipulation (beyond read): The WebDriverManager.cls reads registry keys to detect installed browser versions, a benign activity. There is no evidence of writing to sensitive registry locations for malicious purposes.

The numerous test_ prefixed modules (e.g., test_ActionChains, test_Alerts, test_FileUpDownload) further reinforce that this is a testing and demonstration suite for a legitimate software library. The URLs accessed by the demonstration macros (wikipedia.org, selenium.dev, github.com, vbforums.com, etc.) are either well-known public sites or specific test sites commonly used in web automation development.

In conclusion, the macros represent a sophisticated and functional browser automation library. The "suspicious" functionalities observed (like downloading executables, using system commands, network requests, and base64 operations) are directly aligned with its purpose of controlling web browsers for automation and are not indicative of malicious intent in themselves.

[hanamichi77777]

There have been reports that SelectByIndex does not trigger the change event, but it appears to fire correctly when using Click method.

1. Let's address option selection. WebDriver classic doesn't have a direct command for selecting an option(s) that I am aware of. To emulate option selection, SeleniumVBA improvises with some very naive and possibly poorly devised javascript/FindElement(s) actions which do not handle react elements very well. In this regard, your Bidi scripts are superior. So it's not really that WebDriver classic is failing, but rather SeleniumVBA is buggy. We probably need to fix those with better scripting. Will look into this when I have time.

[hanamichi77777]

I have updated the BiDiSocketCommunicator class to introduce dynamic buffering for enhanced robustness.
The BiDiSocketCommunicator is now highly polished, but the BiDiCommandWrapper may need some cleanup.

[GCuser99]

@hanamichi77777, once I have some time to refactor the Select/Deselect methods, this is what I plan to do with regards to WebDriver Bidi:

• Add EnableBidiMode method to WebCapabilities object
• Add option to WebJsonConverter to leave stringified numbers as strings (and set to True when Bidi Mode is enabled), rather than convert them to type Double. I'd prefer this to just commenting-out lines so that we leave a visible audit trail. The testing that I have done so far shows this should not create any problems - most of the time numbers are encoded as numbers, not strings.

That way, layering your Bidi modules on top of SeleniumVBA should be seamless. I recommend that on your GitHub project that you include source and test modules to make it easier for users include the Bidi layer in their projects. Consider renaming your project to something like "WebDriver Bidi for SeleniumVBA". If you do that, I'll include a link to your GitHub project in our ReadMe.md file. What do you think about that?

More feedback on your Bidi wrapper when i have time...

Thanks!

[dornech]

I appreciate your efforts and support that point of view. If you look ath the Selenium bindings for Python, they are going a similar way and integrate BiDi support in the standard Selenium package. This is inevitable for example to support dynamic loading of extensions because this is only supported via BiDi / WebSocket by the Chrome browser in future.

[GCuser99]

@hanamichi77777, I'm willing to consider integrating Bidi directly into this repo in the future, but I think it's too early for me. I'd rather see it reach a more mature stage before doing so. In the interim, it makes sense to me for you to continue your excellent work in evolving this.

Additionally, I'm very concerned about the impact adding this now will have on AV false positives - we seem to have hit a quite spell recently and I'd hate to jinx that with a lot more code.

However, I'm not speaking for Diego, and if he feels this is mature enough and he wants to integrate and maintain it now, then that's fine with me. I presently don't have the time though.

[hanamichi77777]

I agree. I also don’t think there’s any need to move forward with the integration at this stage. My proposal was intended simply to outline a possible future direction.
To avoid increasing the maintenance burden, I think it would be better for us to take more time to assess the maturity and future trajectory of BiDi, while also carefully considering the risk of AV false positives (such as avoiding the use of CopyMemory).
Of course, once BiDi reaches a sufficiently stable stage in the future, I’d be happy to revisit the discussion and consider integration again.
Until then, I feel it’s best for us to continue working in the current setup.

[6DiegoDiego9]

Hi @hanamichi77777, before give a closer look, I’m also interested in which real-world and popular problems are actually worth solving using some new BiDi capabilities compared to existing methods.
Could you give a few examples?

[hanamichi77777]

The biggest issue I've faced is the lack of a reliable way to wait for asynchronous events to complete. The internal system at my workplace makes extensive use of AJAX asynchronous events, and the automation often proceeds to the next step before the processing is actually finished. Of course, I want to avoid using fixed static waits.

I asked a question(#129) about this, and I'm currently using the solution provided by @dornech.
However, I'm stuck when asynchronous operations other than AJAX occur, as there is no way to handle them.

The reason I started looking into BiDi was to resolve this issue.

[6DiegoDiego9]

Hi @hanamichi77777,

I’m impressed with your BiDi Wrapper. Thanks for building and sharing it!

Now that we have this library to better handle event-driven waits and actions, I’d like to find a way to streamline the “discovery phase”: the identification of which event signatures our scripts should target to work efficiently.

While good CSS/XPath locators are easily and quickly discovered (manually or) by tools like SelectorsHub or AI, because the static source of the web page is sufficient and usually small enough for the LLM context window, identifying the specific network triggers or DOM mutation patterns required for efficient automation is still a manual process for me.

I would love to find, for example, a network log recorder similar to the one in DevTools but much lighter and more efficient, producing useful files smaller than 1M tokens for 10–20 seconds of recording, so that we could use AI to assist in finding the best strategy.

Ideas?

[hanamichi77777]

To be honest, I hadn't considered that use case.
However, since the wrapper already establishes the infrastructure for event subscription and CDP tunneling, I believe you could easily get an AI to generate such a logger for you.
It would just need to filter the incoming network events.

[hanamichi77777]

I have introduced the main09 module, a utility designed to leverage the WebDriver BiDi protocol for recording browser activities. This module generates a structured, noise-filtered log of network and navigation events, providing ideal data for developers—or AI assistants—to analyze page loading behaviors and determine the optimal triggers for automation steps.

Usage and Configuration: The recording process is initiated via the driver.bidi.StartDiscoveryLog method, which accepts the optional boolean argument excludeImagesAndCss.

True (Recommended for Logic Analysis): Filters out static resources such as images, stylesheets, fonts, and analytics trackers. This setting produces a clean, token-efficient log focused on critical API requests and DOM events, making it easier to identify the core logic required for wait strategies.

False (Full Logging): Captures all network traffic without filtering. Use this setting when strictly debugging resource loading issues or when the page behavior depends on specific static assets.

In the main09 sample, I have set this argument to True to prioritize the identification of API endpoints and navigation completion events.

[6DiegoDiego9]

Hi @hanamichi77777,

Thanks for it!
However, I just redownloaded your file from here and did not find the main09 module. Where can I find it?

[hanamichi77777]

Sorry if that was unclear! It's located in the Main09 sub inside the A_01BiDi module.
Running this procedure will create a discovery_log.txt in the same directory.
You can try pasting that log and the entire BiDiSocketCommunicator class into an AI to get advice on the wait strategy.

[hanamichi77777]

To be honest, I'm still experimenting with the best way to arrange the methods in the BiDiSocketCommunicator class. It's probably going to take some time before I can make it public.

[GCuser99]

@hanamichi77777, I know your proposal is meant to be a (quite successful!) proof-of-concept. But like @6DiegoDiego9, I too am interested in determining what more we can currently get from BiDi over and above what we now have with classic WebDriver plus one-way CDP. My first attempt to assess this was to take your BiDi example tests and see what it would take to emulate the same without BiDi. I've gone through most of your tests, excluding the extension, cookie, and login examples, and I seem to be able to do the same with a combination of classic (with scripting) and CDP. I've including one of these tests below.

Here are some preliminary observations:

• I couldn't get your BiDi to work with Firefox/GeckoDriver as-is but I didn't do any further research to understand why
• Your public facing interface seems functionally like a coarser-grained combination of various classic primitives like "do-something and something and wait", by using BiDi, CDP, and scripting. That is perfectly fine, but it makes it harder to compare with our current finer-grained interface.
• One consequence of combining primitives in that way is incurring the (often high) cost of dynamic waiting even when it is not needed. Also, I noticed that many of your waiting scripts have small static waits, which seemed to be what you intended to avoid.
• I have yet to perceive a working example of a circumstance where listening for BiDi events is a significant advantage. In ExecuteNavigateAndGetStatus you wait for "network.responseCompleted" and "browsingContext.load", but doesn't classic WebDriver navigation wait for same when page load strategy is "normal"?
• As an idea for useful event listening, maybe take a look at listening for download events to ensure download is finished before going on to next command - my CDP-only wrapper does this without having to monitor file system mutations like your ExecuteWaitForDownloadCompletion does.

Anyway, even with the observations above, I'm very enthusiastic about the possibilities using BiDi as this develops.

Public Sub test_Main01()
    'test to emulate BiDi Main01 but without extension stuff
    Dim driver As New WebDriver
    Dim elem As WebElement

    driver.StartChrome
    driver.OpenBrowser

    driver.NavigateTo "http://keylopment.com/faq/2357"
    
    'the following 4 code lines emulate ExecuteSelectValueAndWaitByXPath
    Set elem = driver.FindElementByXPath("//select[@name='calselect']")
    elem.SelectByValue "20260301"
    driver.Wait 50 '<- same static wait as in BiDi script GetJsForSelectAndWait
    WaitForIdleState driver, 500 '<- same as used in Bidi script ExecuteSelectValueAndWaitByXPath
    
    Debug.Assert driver.FindElementByXPath("//h3[@class='title-level03']").GetText Like "2026*03*"
    
    driver.CloseBrowser
    driver.Shutdown
End Sub

Public Sub WaitForIdleState(oDriver As WebDriver, Optional ByVal idleTimeout As Long = 1500, Optional ByVal maxTimeToWait As Long = 30000)
    ' This should probably be added to WebDriver class
    Dim script As String
    script = vbNullString
    script = script & "function waitForIdleState(idleTimeout = 1500, maxTimeout = 30000) {" & vbCrLf
    script = script & "return new Promise((resolve) => {" & vbCrLf
    script = script & "  let req = 0, timer = null, settled = false;" & vbCrLf
    script = script & vbCrLf
    script = script & "  const checkInterval = 100;" & vbCrLf
    script = script & "  const of = window.fetch;" & vbCrLf
    script = script & "  const oo = XMLHttpRequest.prototype.open;" & vbCrLf
    script = script & "  const os = XMLHttpRequest.prototype.send;" & vbCrLf
    script = script & vbCrLf
    script = script & "  function cleanup() {" & vbCrLf
    script = script & "    window.fetch = of;" & vbCrLf
    script = script & "    XMLHttpRequest.prototype.open = oo;" & vbCrLf
    script = script & "    XMLHttpRequest.prototype.send = os;" & vbCrLf
    script = script & "    if (timer) clearTimeout(timer);" & vbCrLf
    script = script & "    clearTimeout(safety);" & vbCrLf
    script = script & "  }" & vbCrLf
    script = script & vbCrLf
    script = script & "  function resetTimer() {" & vbCrLf
    script = script & "    if (timer) clearTimeout(timer);" & vbCrLf
    script = script & "  }" & vbCrLf
    script = script & vbCrLf
    script = script & "  function checkIdle() {" & vbCrLf
    script = script & "    resetTimer();" & vbCrLf
    script = script & "    if (req === 0) {" & vbCrLf
    script = script & "      timer = setTimeout(() => {" & vbCrLf
    script = script & "        if (!settled) {" & vbCrLf
    script = script & "          settled = true;" & vbCrLf
    script = script & "          cleanup();" & vbCrLf
    script = script & "          resolve(); // success path" & vbCrLf
    script = script & "        }" & vbCrLf
    script = script & "      }, idleTimeout);" & vbCrLf
    script = script & "    }" & vbCrLf
    script = script & "  }" & vbCrLf
    script = script & vbCrLf
    script = script & "  window.fetch = function (...args) {" & vbCrLf
    script = script & "    req++;" & vbCrLf
    script = script & "    resetTimer();" & vbCrLf
    script = script & "    return of.apply(this, args).finally(() => {" & vbCrLf
    script = script & "      req--;" & vbCrLf
    script = script & "      checkIdle();" & vbCrLf
    script = script & "    });" & vbCrLf
    script = script & "  };" & vbCrLf
    script = script & vbCrLf
    script = script & "  XMLHttpRequest.prototype.open = function (...args) {" & vbCrLf
    script = script & "    return oo.apply(this, args);" & vbCrLf
    script = script & "  };" & vbCrLf
    script = script & vbCrLf
    script = script & "  XMLHttpRequest.prototype.send = function (...args) {" & vbCrLf
    script = script & "    req++;" & vbCrLf
    script = script & "    resetTimer();" & vbCrLf
    script = script & "    this.addEventListener('loadend', () => {" & vbCrLf
    script = script & "      req--;" & vbCrLf
    script = script & "      checkIdle();" & vbCrLf
    script = script & "    });" & vbCrLf
    script = script & "    return os.apply(this, args);" & vbCrLf
    script = script & "  };" & vbCrLf
    script = script & vbCrLf
    script = script & "  setTimeout(checkIdle, checkInterval);" & vbCrLf
    script = script & vbCrLf
    script = script & "  const safety = setTimeout(() => {" & vbCrLf
    script = script & "    if (!settled) {" & vbCrLf
    script = script & "      settled = true;" & vbCrLf
    script = script & "      cleanup();" & vbCrLf
    script = script & "      resolve(""Error: networkIdle timeout"");" & vbCrLf
    script = script & "    }" & vbCrLf
    script = script & "  }, maxTimeout);" & vbCrLf
    script = script & "});" & vbCrLf
    script = script & "}" & vbCrLf
    script = script & vbCrLf
    script = script & "return waitForIdleState(arguments[0], arguments[1]);" & vbCrLf
    If oDriver.ExecuteScript(script, idleTimeout, maxTimeToWait) Like "Error*" Then
        Err.Raise 404, , "Maximum time exceeded for loading page"
    End If
End Sub

[hanamichi77777]

My explanation is not based on guesswork.
It is based on an objective analysis of log data captured by the 'Discovery Recorder,' an AI analysis design proposed by @6DiegoDiego9 that I implemented in mian09.
These logs allow us to derive the appropriate wait strategy.

[GCuser99]

Yes but are you truly using BiDi to detect "Network Idle" state? That script that I proposed is actually just a (minor) reworking of the script that your wrapper uses - so it's not really BiDi that is needed for that - it is JavaScript. I'm going to add WaitForIdleNetwork method to the WebDriver class on the next update. I could be wrong in my assessment, but I challenge you to find an instance where it fails but your BiDi wrapper succeeds. I've tested it on your examples many times now and it works without failure.

[hanamichi77777]

Thank you for waiting. I have prepared a verification HTML file and an .xlsm workbook for this demonstration.
test.html
SeleniumVBA7.2_Classic_vs_BiDi_123.xlsm

Please place the HTML file in the same folder as the .xlsm. The sample is designed so that the value of a text box changes 3 seconds after an item is selected in the select box.

Please try running both the Classic and BiDi procedures within the A_01_BiDiTest module. You will notice a clear difference in their behavior.

The issue in Classic mode is the time lag that occurs between the select box interaction and the execution of WaitForIdleState. This lag causes the system to miss the critical information that network communication has started.

This is due to the fundamental difference in communication protocols (HTTP vs. WebSocket). While adding a manual 3-second wait before Debug.Assert might make the Classic procedure pass, that success is merely a coincidence based on timing.

In BiDi mode, the communication event is captured reliably from the start. As a result, hard-coded wait settings (like the 3-second delay) are completely unnecessary.

[hanamichi77777]

In the above case, Classic can handle it if pre-processing is performed.
It seems that using BiDi is not necessarily required.

Public Sub test_Classic()
    Dim driver As New WebDriver
    Dim elem As WebElement

    driver.StartChrome
    driver.OpenBrowser
    driver.NavigateTo "file:///" & Replace(driver.ResolvePath(".\") & "\test.html", "\", "/")

    InstallNetworkHooks driver

    Set elem = driver.FindElementByXPath("//select[@id='userSelector']")
    elem.SelectByValue "1"

    WaitForIdleStateAsync driver

    Debug.Assert driver.FindElementByXPath("//input[@id='nameField']").GetProperty("value") = "Success: Response Received!"

    driver.CloseBrowser
    driver.Shutdown
End Sub

Public Sub InstallNetworkHooks(oDriver As WebDriver)
    Dim js As String
    js = vbNullString
    js = js & "if(!window.__niw){(function(){" & vbCrLf
    js = js & "var s={req:0,of:window.fetch,oo:XMLHttpRequest.prototype.open,os:XMLHttpRequest.prototype.send,onchange:null};" & vbCrLf
    js = js & "window.fetch=function(){s.req++;if(s.onchange)s.onchange();var p=s.of.apply(this,arguments);return p.finally(function(){s.req--;if(s.onchange)s.onchange();});};" & vbCrLf
    js = js & "XMLHttpRequest.prototype.open=function(){return s.oo.apply(this,arguments);};" & vbCrLf
    js = js & "XMLHttpRequest.prototype.send=function(){s.req++;if(s.onchange)s.onchange();this.addEventListener('loadend',function(){s.req--;if(s.onchange)s.onchange();});return s.os.apply(this,arguments);};" & vbCrLf
    js = js & "window.__niw=s;" & vbCrLf
    js = js & "})();}" & vbCrLf
    oDriver.ExecuteScript js
End Sub

Public Sub WaitForIdleStateAsync(oDriver As WebDriver, Optional idleTimeout As Long = 1500, Optional maxTimeToWait As Long = 30000)
    Dim js As String, ret As Variant
    js = vbNullString
    js = js & "var idleTimeout=arguments[0],maxTimeout=arguments[1],cb=arguments[2];" & vbCrLf
    js = js & "var s=window.__niw;if(!s){cb('not-armed');return;}" & vbCrLf
    js = js & "var tm=null,st=false,safety=setTimeout(function(){done('timeout');},maxTimeout);" & vbCrLf
    js = js & "function done(v){if(st)return;st=true;if(tm)clearTimeout(tm);clearTimeout(safety);cb(v);}" & vbCrLf
    js = js & "function schedule(){if(tm)clearTimeout(tm);if(s.req===0){tm=setTimeout(function(){done('ok');},idleTimeout);}}" & vbCrLf
    js = js & "s.onchange=schedule;" & vbCrLf
    js = js & "schedule();" & vbCrLf
    ret = oDriver.ExecuteScriptAsync(js, idleTimeout, maxTimeToWait)
    If ret <> "ok" Then Err.Raise 404, , "Maximum time exceeded or context lost: " & ret
End Sub

[GCuser99]

@hanamichi77777, thanks for the tests above. I'm stepping away from this for the moment but will get back to you when I can dedicate some time to look at this. In the meantime, can you tell me more about the problem? As far as I can tell, in none of your original tests (9 or 10 of them) was listening for the network.responseCompleted necessary. Is that because this delayed network response is only a real issue for you at work? I'm asking that to better understand under what circumstances this is likely a problem that needs a solution, and how common those circumstances occur in the wild. Anyway, I'll try to get back to you within a week or two. Thanks again!

[hanamichi77777]

Regarding Pipe Mode (Comparison with WebDriver BiDi via WebSocket)
https://github.com/longvh211/Chromium-Automation-with-CDP-for-VBA/releases/tag/2.7

I consulted with Gemini, and the benefits of the Pipe method are indeed significant. Theoretically, Edge and Chrome browsers can read not only CDP commands but also BiDi commands (W3C Standard) via pipes (Puppeteer actually does this, utilizing BiDi without a WebDriver). Currently, the transition from CDP to BiDi is strongly recommended in the long term, and it seems we can handle this transition simply by rewriting the commands to BiDi when that time comes.

Benefits (Reasons for Selection)

Overwhelming "High Speed & Low Latency"
Reason: It does not go through TCP/IP (the network layer) but reads and writes data directly via the OS kernel memory.
Benefit: In "heavy processing" tasks, throughput is improved compared to WebSocket when retrieving large amounts of data (such as the entire page source or huge JSON files).

Completely "Driverless" and "Easy to Distribute"
Reason: No WebDriver is required. It works with just the xlsm file (or in combination with xlam).
Benefit: There is no need for users to manage driver versions, realizing the ultimate portability where "it works as long as you have Excel."

Resistant to Antivirus & Firewalls
Reason: It does not execute external EXEs nor perform network communication.
Benefit: The risk of false positive detections can be minimized.

Disadvantages (Constraints to Accept)

Inability to Attach to an "Already Running Browser" (Major Weakness)
Detail: Pipes can only connect at the time of process creation (CreateProcess).
Impact: It is impossible to take control of an Edge browser manually opened by the user midway. It must always be launched via New from VBA.

Complete Loss of Compatibility with Selenium Classic (For Existing Selenium Users)
Detail: Traditional Selenium relies on HTTP communication via a driver, but the Pipe method does not use this path at all.
Impact: Traditional methods like FindElementBy... and existing code cannot be reused; everything must be rewritten using the new syntax (CDP/BiDi).

Increased Difficulty in Debugging
Detail: If the communication is cut off, the link with the browser is completely lost.
Impact: If VBA resets (terminates) due to an error, the browser becomes an uncontrollable "zombie" process (whereas WebSocket allows for reconnection and investigation, provided port 9222 is used).

[hanamichi77777]

This BiDiSocketCommunicator class module incorporates specific optimizations to achieve practical performance for "asynchronous and bidirectional" WebSocket communication, despite the inherent constraints of VBA being "single-threaded and synchronous (sequential processing)."The "ingenuities (strategies to overcome VBA's limitations)" in this code can be summarized into the following five main points:

1. Pseudo-Asynchronous Processing via "Adaptive Polling"
VBA lacks a mechanism like JavaScript's "Event Listeners" (where a function runs automatically when data arrives). Therefore, it is necessary to actively check for data (polling). However, doing this simply will either cause CPU usage to skyrocket or result in delayed responses.
This code implements a strategy within the GetMessage method to switch between "Burst Mode" and "Idle Mode."

Common Challenges:
Constant monitoring in a loop causes Excel to go "Not Responding" (freeze) and monopolizes the CPU.
Inserting Sleep slows down processing speed when a large volume of data arrives.

Solution in this Code:
・Burst Mode: Immediately after receiving data (just after p_lastActivityTime is updated), the code ignores wait times and reads continuously (using a trick where nowT + 1000 sets a future time to trigger an immediate next loop).
・Idle Mode: When no data has arrived for a while, it spaces out checks by m_PollingInterval (e.g., 1 second) to let the CPU rest.
・Keep-Alive: To prevent disconnection during idle times, logic is included to send an explicit Ping (session.status) in addition to WinHttp option settings.

2. WebSocket Implementation via Direct WinHttp API Calls
Standard VBA objects like MSXML2.XMLHTTP or WinHttp.WinHttpRequest are usable for HTTP requests (single exchanges) but do not support the WebSocket protocol (persistent connections).

Ingenuity:
・The code directly declares and uses Win32 APIs such as WinHttpOpen, WinHttpWebSocketCompleteUpgrade, and WinHttpWebSocketSend/Receive.
・This bypasses the limitations of standard VBA libraries, utilizing OS-level networking features to realize the HTTP-to-WebSocket upgrade handshake.

3. High-Speed "UTF-8 Binary" Processing via ADODB.Stream
VBA's String type is internally Unicode (UTF-16 LE), but the Web standard is UTF-8.

Common Challenges:
・The API returns byte arrays (UTF-8). Forcibly converting this using VBA’s StrConv results in garbled text (mojibake).

Solution in this Code:
・It utilizes the ADODB.Stream object.
・By holding and reusing m_Stream at the class level, writing as adTypeBinary, and reading as adTypeText (Charset = "UTF-8"), it performs character encoding conversion quickly and accurately.
・This ensures JSON data containing Japanese characters is handled correctly.

4. Dynamic Buffer Resizing
WebSocket data varies significantly in size, from messages of a few bytes to image data (Base64) of several megabytes.

Ingenuity:
・The MaybeGrowBuffer method counts how many times the received data fills the buffer size (initial 8KB) (m_RecentFullReads).
・During high loads where the buffer fills continuously, the buffer size is doubled iteratively up to a maximum of 64KB (m_MaxBufferSize).
・This achieves optimization by "saving memory for small messages while reducing communication overhead to speed up large data transfers."

5. Avoiding "Excel Freeze" and Protecting UI Operations
Running long loop processes in VBA causes the Excel screen to turn white and become "Not Responding."

Ingenuity:
・The YieldExecution method combines the Windows API Sleep (precise millisecond waiting) with VBA's DoEvents.
・Specifically, the m_AllowUiPump property controls whether DoEvents (which returns control to the OS) is executed.
・Carelessly repeating DoEvents during communication can cause "Re-entrancy" bugs (where the user edits cells or presses buttons during the process); making this controllable via a flag is a practical consideration for real-world use.

[hanamichi77777]

The BiDiCommandWrapper class is designed to break through the limitations of traditional WebDriver (Classic/HTTP-based) by fully utilizing the capabilities of WebDriver BiDi (Bi-Directional) and CDP (Chrome DevTools Protocol). Based on the code implementation, here are 5 specific points explaining how it is superior to the traditional Classic approach.

1. Elimination of Wait Times and Acceleration via "Event-Driven" Architecture
The traditional Classic version relied on a repetition of "Send Command → Wait for Response (Blocking)." This class uses WebSocket to receive push notifications from the server (browser).

Challenge (Classic): To detect page load completion, it requires polling ("Is it done yet?") multiple times, which results in high CPU load or latency.
Benefit (BiDi): It subscribes to events such as browsingContext.load via ExecuteSessionSubscribe.
Code Evidence: Inside the ExecuteClickAndNavigateByXPath method.
Explanation: Instead of waiting with Sleep after a click, it monitors the socket for browsingContext.fragmentNavigated (SPA screen transitions) or load events. This allows the process to move to the next step the instant the transition completes, reducing wasted wait time to zero.

2. Powerful "Smart Recovery" Functionality
It includes robust recovery features for the most troublesome errors in VBA Selenium, such as StaleElementReferenceException (element is old) and NoSuchFrame (frame not found).

Challenge (Classic): If a page updates during operations within a frame, the reference breaks, causing the script to stop with an error. It requires writing manual code to restart from SwitchTo.DefaultContent.
Benefit (BiDi): It manages the contextId and realmId (script execution area ID) and automatically re-acquires IDs when an error occurs.
Code Evidence: ExecuteActionWithStaleRetry method.
Explanation: When it detects context destroyed or stale errors, it calls GetScriptRealmId(forceUpdate:=True) inside a loop to fetch a new ID and retry immediately. The user can write code without being conscious of frame reloads.

3. "Network-Level" Control via CDP Integration
This class directly utilizes Chrome DevTools Protocol (CDP) functions via goog:cdp.sendCommand, which is impossible with WebDriver Classic.

Challenge (Classic): Blocking image loading or specific traffic is impossible without setting up a proxy server.
Benefit (BiDi): It allows direct intervention in the browser's network layer.
Code Evidence: ExecuteEnableResourceBlocking / ProcessCDPBlockingEvent.
Explanation: It uses Network.setBlockedURLs or Fetch.enable to block images or unnecessary scripts at the browser level. This dramatically improves scraping speed and reduces data usage.

4. Freeze Avoidance and Asynchronous Alert Handling
Since VBA is single-threaded, if an alert (dialog) appears, processing is blocked, often rendering the application inoperable.

Challenge (Classic): Clicking a button that triggers an alert prevents VBA from proceeding to the next line of code until the alert is closed, potentially causing a deadlock (freeze).
Benefit (BiDi): It realizes asynchronous clicking and alert handling.
Code Evidence: ExecuteClickAndHandleAlertByXPath.
Explanation: It injects JavaScript setTimeout(..., 0) to "schedule" the click processing and immediately returns control to the VBA side. Immediately after, it sends browsingContext.handleUserPrompt to handle the alert without freezing VBA.

5. "Discovery Recorder" Designed for AI Analysis
This is an advanced feature unique to this class that does not exist in traditional drivers.

Challenge (Classic): To create automation scenarios, one had to visually inspect the browser's Developer Tools to know which APIs were called or when the DOM changed.
Benefit (BiDi): It records communication logs as structured data behind the scenes of automatic operations.
Code Evidence: StartDiscoveryLog / FormatAndStoreLog.
Explanation: It hooks events like network.responseCompleted and records them chronologically. This log is formatted for "token efficiency," making it optimized data to feed into an LLM (like ChatGPT) to instruct it to "devise a strategy for this site."

Conclusion
This BiDiCommandWrapper is not merely a wrapper for WebDriver, but a next-generation browser automation engine equipped with "Traffic Control," "Self-Healing," and "Observability."

If the traditional Classic version is a tool that "mimics a human operating a browser by hand," this BiDi version is distinctively a tool that "connects directly to the browser's cranial nerves (DevTools) to manipulate it."

However, please note that sufficient testing has not yet been conducted, so unexpected bugs may occur. A dedicated testing period is required to identify and fix these issues.

[GCuser99]

So is that AI's response to my last post? I get it that AI is very impressed with its own work! :-) But that response did not address any of my points of concern...

Anyway, if I was developing a BiDi layer for SeleniumVBA, I think I would be inclined to create a wrapper that would leverage BiDi only (without CDP since we already have that with classic). I'd start with the most important functional primitives such as navigation, element locators, and common element interactions, making improvements relative to WebDriver classic where (or if) possible. Also, if we are going to continue to support Firefox in SeleniumVBA, then leaving CDP out of the BiDi wrapper would be essential, I think.

[hanamichi77777]

I've looked at the proposed code, but unfortunately, I currently don't have the environment to test it, so I can't verify it at the moment. I apologize for not being able to provide an immediate answer.

While I know AI isn't perfect, I unfortunately lack the expertise to fully decipher the code on my own without running it. This makes rigorous testing absolute essential for me, but setting up that environment is difficult right now. I believe we should not implement this unless it can be tested thoroughly.

[GCuser99]

BTW, I was not proposing any code - just showing that the same can be accomplished in WebDriver classic. It looks like to me that your BiDi wrapper is mostly doing things that can already be done with current functionality. It's a valid question to ask "what can BiDi buy me now, and what will it buy me in the future as it evolves." I'm trying to discern the "now" part. It's hard for me to assess that with the way the wrapper is currently written. One possible benefit now would be the BiDi extension manager (@dornech mentioned above) - can we do something with that now that we cannot do with WebDriver classic?

[hanamichi77777]

One possible benefit now would be the BiDi extension manager (@dornech mentioned above) - can we do something with that now that we cannot do with WebDriver classic?

Yes, it is possible. The code is in the standard module A_01BiDi main01.
Please ensure that the Google Translate extension is installed in advance.

' Enable Chrome extension
Dim extensionPath As String
extensionPath = Environ("LOCALAPPDATA") & "\Google\Chrome\User Data\Default\Extensions\aapbdbdomjkkjkaonfhkkikfgjllcleb\2.0.16_0"
.bidi.ExecuteWebExtensionInstall (extensionPath)

[GCuser99]

Can this not be done with WebDriver classic? It would be useful to see a side-by-side comparison showing where one breaks and the other succeeds...

[hanamichi77777]

Main10 uses the BiDi protocol, while Main11 uses the Classic protocol.

Public Sub Main10()
 Dim driver As WebDriver: Set driver = New WebDriver
  With driver
    
  ' Start
  .StartChrome
    
  ' Browser startup settings (for both Chrome and Edge)
  Dim caps As SeleniumVBA.WebCapabilities: Set caps = .CreateCapabilities
  
  ' Required to enable Chrome extensions
  caps.AddArguments "--remote-debugging-pipe"
  caps.AddArguments "--enable-unsafe-extension-debugging"
  ' ==========================================
  ' Enable BiDi (True is mandatory for this program)
  caps.SetCapability "webSocketUrl", True
  ' ==========================================
  
  ' Open
  .OpenBrowser caps
      
  ' Enable Chrome extension
   Dim extensionPath As String
   extensionPath = Environ("LOCALAPPDATA") & "\Google\Chrome\User Data\Default\Extensions\aapbdbdomjkkjkaonfhkkikfgjllcleb\2.0.16_0"
   .bidi.ExecuteWebExtensionInstall (extensionPath)
         
   Stop
         
  ' End
  .CloseBrowser
  .Shutdown
      
  End With
End Sub

Public Sub Main11()
 Dim driver As WebDriver: Set driver = New WebDriver
  With driver
    
  ' Start
  .StartChrome
    
  ' Browser startup settings (for both Chrome and Edge)
  Dim caps As SeleniumVBA.WebCapabilities: Set caps = .CreateCapabilities
 
 'temporary work-around for this issue: https://github.com/SeleniumHQ/selenium/issues/15788
  caps.AddArguments "--disable-features=DisableLoadExtensionCommandLineSwitch"

  'this will load an unpacked extension from Chrome's User Data extensions directory
   caps.AddArguments "--load-extension=" & Environ("LOCALAPPDATA") & "\Google\Chrome\User Data\Default\Extensions\aapbdbdomjkkjkaonfhkkikfgjllcleb\2.0.16_0"
  
  ' Open
  .OpenBrowser caps

   Stop

  ' End
  .CloseBrowser
  .Shutdown
      
  End With
End Sub

[dornech]

Can this not be done with WebDriver classic? It would be useful to see a side-by-side comparison showing where one breaks and the other succeeds...

I use the Python Bindung in parallel. The standard extension API was deactivated in Chrome due to security reasons. With standard webdriver you cannot fully automate extension installation any longer. This works with Chrome (but also with some limitations). Feel free to look here
SeleniumHQ/selenium#16541

[dornech]

Another issue that could be easend via BiDi: setting download defaults. So far you have to differentiate browser type dependent.
When looking at the Python BiDi bindings, it looks like BiDi offers a common way to set the download behaviour. Have a look at line 239 ff
https://github.com/SeleniumHQ/selenium/blob/trunk/py/selenium/webdriver/common/bidi/browser.py

However, I learned that even an BiDi API call exists in the Python binding, it does not mean the API is supported by every browser. So it might be the case that browser independence of code is not (yet) achievable via BiDi at least not without additional workarounds

[GCuser99]

I tried using @hanamichi77777 Main10 and Main11 subs. I don't use extensions in my automation so I might be doing something wrong - weigh my experience appropriately...

Main10 (BiDi) did successfully load the extension, but I had to manually click on the extension icon, and then click on the actual Google Translate extension to activate it.

Using Main11 (classic) it was a complete fail - did not see the extension icon at all.

So from an automation perspective, they both failed for me, but BiDi got me one step closer... @dornech - is there an easy way to activate the extension after loading using BiDi?

As far as FireFox goes, it appears to me that @hanamichi77777's current BiDi setup won't connect to geckodriver.

[dornech]

Well with VBA I still use the classic Webdriver - which ends up in Chrome having to manually confirm the extension installation. I navigate via chrome://extensions to check if installed and otherwise install from https://chromewebstore.google.com/detail/ + Extension-ID. Then I have to manually confirm the installation and it is activated.

' check browser extension is installed and install via ChromeWebStore if not(only Chrome)
Sub checkBrowserExtensionsInstalled_Chrome(ByVal s_WebdriverBrowser As String, s_BrowserExtensions As Variant, ByRef objWebDriver As WebDriver)

   Dim _
      i_Height As Integer, _
      i_Width As Integer, _
      i_Idx As Integer, _
      i_Count As Integer, _
      i_Try As Integer, _
      lng_WinHandle As Long, _
      s_BrowserExtension_ID As String

   If (s_WebdriverBrowser <> s_WebdriverBrowser_Chrome) Then Stop

   If Not IsMissing(s_BrowserExtensions) Then
      If Not IsArray(s_BrowserExtensions) Then
         If InStr(1, s_BrowserExtensions, ",") Then
            s_BrowserExtensions = Split(s_BrowserExtensions, ",")
         ElseIf InStr(1, s_BrowserExtensions, ";") Then
            s_BrowserExtensions = Split(s_BrowserExtensions, ";")
         ElseIf InStr(1, s_BrowserExtensions, ";") Then
            s_BrowserExtensions = Split(s_BrowserExtensions & ";", ";")
         End If
      End If
      If IsArray(s_BrowserExtensions) Then

'        enable developer mode
         Call objWebDriver.NavigateTo("chrome://extensions/")
         Call findElementShadowDOM(objWebDriver, "//extensions-manager", Array("extensions-toolbar", "cr-toolbar > div.more-actions > cr-toggle")).Click

'        set width to make extension search field visible
         i_Height = objWebDriver.ActiveWindow.Bounds("height")
         i_Width = objWebDriver.ActiveWindow.Bounds("width")
         objWebDriver.ActiveWindow.SetSize 1300, i_Height

         For i_Idx = LBound(s_BrowserExtensions) To UBound(s_BrowserExtensions)
            If (s_BrowserExtensions(i_Idx) <> vbNullString) Then
               s_BrowserExtension_ID = getParamFromINIfile("SeleniumWebUtils", s_BrowserExtensions(i_Idx) & "_ID", s_WebdriverBrowser, vbNullString)
               If (s_BrowserExtension_ID <> vbNullString) Then
                  Call objWebDriver.NavigateTo("chrome://extensions/")
                  Call findElementShadowDOM(objWebDriver, "//extensions-manager", Array("extensions-toolbar", "cr-toolbar", "div > cr-toolbar-search-field", "div#content > div#searchTerm > input")).SendKeys(s_BrowserExtension_ID)
                  i_Count = findElementsShadowDOM(objWebDriver, "//extensions-manager", Array("div > cr-view-manager > extensions-item-list", "div > div > div#extensions-section > div.items-container > extensions-item")).Count
                  If i_Count = 0 Then
                     Debug.Print "Extension '" & s_BrowserExtensions(i_Idx) & "' not yet installed."
                     Call objWebDriver.NavigateTo("https://chromewebstore.google.com/detail/" & s_BrowserExtension_ID)
                     Call objWebDriver.FindElementByXPath("//c-wiz/div/div/main/descendant::button").Click
'                    try automated confirmation via SendKeys -> does not work
'                    lng_WinHandle = FindWindowByPartialTitle("Chrome Web Store")
'                    SendMessage lng_WinHandle, WM_KEYDOWN, 9, 0
'                    DoEvents
'                    SendMessage lng_WinHandle, WM_KEYUP, 9, 0
'                    DoEvents
'                    SendMessage lng_WinHandle, WM_KEYDOWN, 13, 0
'                    DoEvents
'                    SendMessage lng_WinHandle, WM_KEYUP, 13, 0
'                    DoEvents
'                    request manual confirmation if try with SendKeys not successful
                     Call MsgBox("Please confirm to install extension '" & s_BrowserExtensions(i_Idx) & "' and press OK.")
                     Call waitHTMLstable(objWebDriver)
                  ElseIf i_Count = 1 Then
                     Debug.Print "Extension '" & s_BrowserExtensions(i_Idx) & "' already installed."
                  ElseIf i_Count = 2 Then
                     Debug.Print "ID for extension '" & s_BrowserExtensions(i_Idx) & "' is not unique."
                  End If
               Else
                  Debug.Print "ID for extension '" & s_BrowserExtensions(i_Idx) & "' could not be determined."
               End If
            End If
         Next

         objWebDriver.ActiveWindow.SetSize i_Width, i_Height

      End If
   End If

End Sub

With Python I use the BiDi API method from the Selenium language binding and the extension is isntalled and activated. (however I made some code to overcome the trouble with BiDi for Chrome not supporting archive extension files - see link to issue raised above).

[hanamichi77777]

If you are unable to connect to Firefox, please specify the path using the SetBrowserBinary method.

' Start
  .StartFirefox
    
  ' Browser startup settings (for both Chrome and Edge)
  Dim caps As SeleniumVBA.WebCapabilities: Set caps = .CreateCapabilities
  
   'FireFox
   caps.SetBrowserBinary Environ("ProgramFiles") & "\Mozilla Firefox\firefox.exe"
  ' ==========================================
  ' Enable BiDi (True is mandatory for this program)
  caps.SetCapability "webSocketUrl", True
  ' ==========================================
' Open
  .OpenBrowser caps

[hanamichi77777]

Sorry, the same issue has occurred again. I'm checking the details now.

[hanamichi77777]

I have identified the cause.
It is due to a specific technical requirement in Firefox.
When using Firefox with BiDi, the port must be 9222 instead of the standard 4444.
I have updated the code below.
Please try running main03.

https://github.com/hanamichi77777/WebDriverBiDi-via-VBA-test/blob/main/SeleniumVBA7.0_BiDi_Test_123.xlsm

[GCuser99]

Ok, that works for me now - thanks!

So now your big decision is, with CDP mixed in with your BiDi, whether you want your wrapper to fully support Firefox or not. If it were my project, I think I would first try to take this in the direction of pure BiDi with a focus on improving on the functionality that we already have (or could have) with classic. In addition to potentially allowing full FF support, which SeleniumVBA cannot easily do, it would also more clearly showcase the potential advantages of BiDi. But maybe that's not practical right now?

[hanamichi77777]

At present, BiDi alone lacks several critical features, so relying on CDP is necessary to make the wrapper truly useful. I also fully understand the immense effort you put into maintaining Firefox support in the Classic version.

To ensure the stable and long-term sustainability of SeleniumVBA, I believe it is important to reduce the maintenance burden by limiting support to Edge and Chrome, rather than chasing Firefox compatibility.

[hanamichi77777]

By the way, while Playwright achieves high-level control over Firefox, this is not done via BiDi. Instead, they utilize a patched version of Firefox that has been modified to understand CDP commands. I think this illustrates just how difficult it is for a solo project like SeleniumVBA to aim for that level of Firefox support (especially features equivalent to CDP).

[GCuser99]

SeleniumVBA v7.1 is now BiDi compatible, meaning it should work with @hanamichi77777's BiDi layer (or anyone else's) without having to make any changes to WebJSonConverter. I added a method to WebCapabilities class called EnableBiDiMode that sets the right capability and tells WebJSonConverter not to convert stringified numbers into numbers, which was messing up BiDi realmId's.

Although not really related to BiDi, I also added some smart waits similar to what @hanamichi77777's BiDi wrapper was using - here is one example using WaitForIdleJQuery that waits until all active jQuery AJAX requests have completed, polling until the page reaches a jQuery-idle state or a timeout occurs:

Public Sub Main01()
    'Test for waiting after selecting (without extension)
    Dim driver As WebDriver
    Dim elem As WebElement

    Set driver = New WebDriver
    driver.StartChrome
    
    driver.OpenBrowser
    driver.ActiveWindow.Maximize

    driver.ImplicitMaxWait = 10000

    driver.NavigateTo "http://keylopment.com/faq/2357"
    
    Set elem = driver.FindElementByXPath("//select[@name='calselect']")
    
    elem.SelectByValue "20260301"

    driver.WaitForIdleJQuery '<- waits less than half the time as a WaitForIdleNetwork

    Debug.Assert driver.FindElementByXPath("//h3[@class='title-level03']").GetText Like "2026*03*"
    
    driver.CloseBrowser
    driver.Shutdown
End Sub

[hanamichi77777]

Thank you for implementing WebDriver BiDi!
I plan to continue my testing based on version 7.1 moving forward.
While I'm keeping a close eye on AV trends, I hope to report false positives effectively by leveraging the explanations from Code Insights.

[GCuser99]

Oh wait - I see you made changes to WebDriver to accommodate BiDi. Are there any other changes besides these that you made?

Private m_BiDiSocket As BiDiSocketCommunicator
Private m_BiDiWrapper As BiDiCommandWrapper

Private webSocketUrl_ As String

' Description: Access point for BiDi (WebDriver Bi-Directional) features.
Public Property Get bidi() As BiDiCommandWrapper
    Set bidi = m_BiDiWrapper
End Property

Public Property Get socket() As BiDiSocketCommunicator
    Set socket = m_BiDiSocket
End Property

Public Property Get GetWebSocketUrl() As String
    GetWebSocketUrl = webSocketUrl_
End Property

' Get Local Port
Public Property Get GetLocalPort() As String
    ' Reliably extracts the port number from the URL (e.g., "http://localhost:9515")
    Dim parts() As String
    ' Split by colon and retrieve the last element
    parts = Split(driverUrl_, ":")
    
    If UBound(parts) > 0 Then
        ' Return the last part (e.g., 9515)
        GetLocalPort = parts(UBound(parts))
    Else
        ' Fallback in case of error (default value)
        GetLocalPort = "0"
    End If
End Property

'in OpenBrowser:

    ' ==========================================================
    ' BiDi (WebSocket) Auto-Connect & Setup
    ' ==========================================================
    webSocketUrl_ = resp("capabilities")("webSocketUrl")
    If webSocketUrl_ <> vbNullString Then
        ' 1. Create instances if they don't exist
        If m_BiDiSocket Is Nothing Then Set m_BiDiSocket = New BiDiSocketCommunicator
        If m_BiDiWrapper Is Nothing Then Set m_BiDiWrapper = New BiDiCommandWrapper
        
        ' 2. Attempt Connection
        If m_BiDiSocket.AttemptAutoConnect(Me) Then
            ' 3. Wire them together
            Set m_BiDiWrapper.SetDriver = Me
            Set m_BiDiWrapper.SetSocket = m_BiDiSocket
        End If
    End If

[GCuser99]

I want to decouple SeleniumVBA's WebDriver class from your BiDi classes so that anyone can add their own BiDi layer to SeleniumVBA. That way we are not hardwiring your BiDi stuff to our WebDriver class. So maybe it could look something like this:

  Dim driver As New WebDriver
  Dim bidi as New BiDiCommandWrapper 
  Dim caps As WebCapabilities
    
  driver.StartChrome

  Set caps = driver.CreateCapabilities
  caps.EnableBiDiMode 'enable from the WebDriver side
  driver.OpenBrowser caps
      
  ' Enable from the BiDi side 
  bidi.Connect driver.GetLocalPort
  'or maybe bidi.ConnectTo driver

  ' Now do all sorts of cool stuff with bidi object
  bidi.DothisAndDoThatAndWait()

In the WebDriver class, we could have the necessary read-only properties to accommodate connection, such as GetLocalPort. Is the local port the only thing your BiDi wrapper needs to connect?

Does that sound ok to you? Does it make sense? Are you willing to rewrite your BiDi code to allow this way of connecting?

[hanamichi77777]

I see your point, but it's a difficult matter to give an immediate answer to.
There are several hurdles to clear, so we’ll need to take some time to verify the details.

[hanamichi77777]

The verification is complete. By refactoring the driver class as follows, we can utilize BiDi while eliminating dependencies. The LocalPort and webSocketUrl_are the essential pieces of information required to establish WebSocket communication.
Since we need to retrieve the webSocketUrl, additional code must be added to the OpenBrowser procedure. This code is generic in nature. Below is the minimum required code for the driver class.
If there is a cleaner way to write the code for retrieving the local port, that works for me as well.

'Add to the Declarations section
Private webSocketUrl_ As String

'Add after sessionId_ = resp("sessionId") in Public Sub OpenBrowser.
webSocketUrl_ = resp("capabilities")("webSocketUrl")

’Add the following code at any location.
Public Property Get GetWebSocketUrl() As String
    GetWebSocketUrl = webSocketUrl_
End Property

Public Property Get GetLocalPort() As String
    ' Reliably extracts the port number from the URL (e.g., "http://localhost:9515")
    Dim parts() As String
    ' Split by colon and retrieve the last element
    parts = Split(driverUrl_, ":")
    
    If UBound(parts) > 0 Then
        ' Return the last part (e.g., 9515)
        GetLocalPort = parts(UBound(parts))
    Else
        ' Fallback in case of error (default value)
        GetLocalPort = "0"
    End If
End Property

Add the following code to the Standard Module.
The line Dim bidi As New BiDiCommandWrapper: bidi.Connect driver can be left to each product's specific implementation.

Public Sub test()
  Dim driver As WebDriver: Set driver = New WebDriver
  With driver
   
  ' Start
  .StartChrome
   
  ' Browser startup settings (for both Chrome and Edge)
  Dim caps As WebCapabilities: Set caps = .CreateCapabilities
  ' ==========================================
  caps.EnableBiDiMode
  ' ==========================================
    
  ' Open
  .OpenBrowser caps
  ' ==========================================
   Dim bidi As New BiDiCommandWrapper: bidi.Connect driver
  ' ==========================================

The following is a test file that incorporates the above code.
It is working as expected.
SeleniumVBA7.1_BiDi_Test_123tmp.xlsm

[hanamichi77777]

That is an excellent point.
I used the method you suggested to find the Firefox port.
I believe this will allow for flexible adjustments even if the port changes in the future.

[hanamichi77777]

Also, it's not my business but can I just suggest a small change? bidi.ConnectTo driver?
Please feel free to ask me anything.

SeleniumVBA7.1_BiDi_Test_123tmp.xlsm

[GCuser99]

Ok, I exposed the GetWebSocketUrl Property as per your suggestion above. Attached is the proposed WebDriver class - let me know if it can work for you and if so, I will update the GitHub repo.

WebDriver.zip

[hanamichi77777]

I'm going out now, so I might be slow to respond for a while.

[hanamichi77777]

Confirmation complete. It worked without any issues using the provided driver class. The WebSocketUrl information alone was sufficient. The files after verification are as follows:
SeleniumVBA7.1_BiDi_Test_123tmp.xlsm

The standard modules are as follows.
Thank you.

Public Sub test()
  Dim driver As WebDriver: Set driver = New WebDriver
  With driver
   
  ' Start
  .StartChrome
   
  ' Browser startup settings (for both Chrome and Edge)
  Dim caps As WebCapabilities: Set caps = .CreateCapabilities
  ' ==========================================
  caps.EnableBiDiMode
  ' ==========================================
    
  ' Open
  .OpenBrowser caps
  ' ==========================================
   Dim bidi As New BiDiCommandWrapper: bidi.ConnectTo .GetWebSocketUrl
  ' ==========================================
   bidi.～

[hanamichi77777]

Thank you for the update to version 7.2!
It appears that the file "SeleniumVBA_with_pw_123.xlsm" is not password-protected.
Could you please look into this?

[GCuser99]

Done - thanks!

[GCuser99]

@dornech - have you tried @hanamichi77777's Main01 extension loading example? I tested on two different unpacked extensions (Google translate and an add blocker) and managed to load them without having to manually click. Not sure why I came to the earlier conclusion that it needed a manual click. Maybe you should give it a go just to see if it works for you?

[dornech]

No I can't open the file. It shows a file type error?

However, with BiDi it is what expect: no manual click.
The manual click is required with my method going via the webstore. This was my Chrome specific workaround due to the old API not supported by Chrome any longer.

[GCuser99]

@hanamichi77777 - is it possible to also include the source (two classes and test module) in your GitHub repo now that we decoupled your BiDi layer from SeleniumVBA v7.2 source?

[hanamichi77777]

Thank you for the wonderful proposal! Please give me a few more days to finalize the files. I am currently refactoring the code to ensure it is clean and ready for integration. I will submit the source code shortly.

Regarding Firefox, I have been investigating its WebSocket URL behavior. For example, Firefox returns a URL like: ws://127.0.0.1:9222/session/4a4c94f9-e2e7-41bf-82bd-f75fec30a5df

Unlike Chrome or Edge, the string does not contain "localhost". While it is technically possible to parse the port from this format, it would increase maintenance overhead significantly. Furthermore, Firefox does not support the CDP features that I have integrated into this BiDi layer.

Based on these factors, I am planning to exclude Firefox support from this implementation to keep the codebase stable and focused on Chromium-based browsers.

Does this sound acceptable to you?

[hanamichi77777]

Oh, I see—I misunderstood. Since it’s just a matter of hosting the source code in the repository, the lack of Firefox support won't have any impact at all.

[hanamichi77777]

I have uploaded the updated files.
Please feel free to use them.
Please be aware that there may be frequent updates in the near future.
https://github.com/hanamichi77777/WebDriverBiDi-via-VBA-test

[GCuser99]

In case anyone want's to test the BiDi extension capabilities:

1. Load the two class modules BiDiCommandWrapper.cls and BiDiSocketCommunicator.cls from @hanamichi77777's GitHub above into your SeleniumVBA project (v7.2 required).
2. Copy and paste the following test Sub into your project.
3. Modify the extensionPath variable to point to your unpacked extension
4. Run it!

I have used one of @hanamichi77777's use cases below but had modify to handle Unicode on my system. This is a great example of where BiDi can come in handy, as there seems to be no other way now to load an extension at runtime.

Public Sub test_BiDi_extensions()
    Dim driver As New WebDriver
    Dim caps As WebCapabilities
    
    ' Handle Unicode literals as my system does not allow in VBA IDE
    Dim TOKYO As String: TOKYO = ChrW$(&H6771) & ChrW$(&H4EAC)
    Dim SHINJUKU As String: SHINJUKU = ChrW$(&H65B0) & ChrW$(&H5BBF)
    
    driver.StartChrome
    
    Set caps = driver.CreateCapabilities
    
    ' Required to enable Chrome extensions in BiDi
    caps.AddArguments "--remote-debugging-pipe"
    caps.AddArguments "--enable-unsafe-extension-debugging"

    ' Enable BiDi Mode
    caps.EnableBiDiMode
    
    driver.OpenBrowser caps

    ' Instantiate BiDi and connect it to WebDriver
    Dim bidi As New BiDiCommandWrapper: bidi.ConnectTo driver.GetWebSocketUrl

    ' Enable Chrome extension - modify path to your unpacked extension, such as add blocker
    Dim extensionPath As String
    extensionPath = Environ("UserProfile") & "\Documents\SeleniumVBA\extensions\odjhnkahfagmgepoigjbindpjnmgainl\1.4_0"
    bidi.ExecuteWebExtensionInstall (extensionPath)
    
    driver.ActiveWindow.Maximize
    driver.ImplicitMaxWait = 5000
    
    ' Navigate to website
    driver.NavigateTo "https://transit.yahoo.co.jp/"
    
    ' Departure: Tokyo
    driver.FindElementByXPath("//input[@name='from']").SendKeys TOKYO & WebKeyboard.EnterKey

    ' Arrival: Shinjuku
    driver.FindElementByXPath("//input[@name='to']").SendKeys SHINJUKU & WebKeyboard.EnterKey

    ' Date/Time: Last train
    driver.FindElementByXPath("//*[@id='tsLas']").Click

    ' Display order: Lowest price
    driver.FindElementByXPath("//select[@id='s']").SelectByValue "1"

    ' Click search button
    driver.FindElementByXPath("//input[@id='searchModuleSubmit']").Click

    ' Test to see if we got there!!
    Set elem = driver.FindElementByCssSelector("#rsltlst > li:nth-child(1) > dl > dt > a")
    Debug.Assert elem.GetAttribute("href") = "#route01"

    driver.CloseBrowser
    driver.Shutdown
End Sub

[dornech]

Hi,
coming back to the question of advantages of BiDi and improved waits: I found a Python module adressing just this issue. It uses also some script injection. I have not tested it yet but seems of interest.
https://www.dhirajdas.dev/blog/waitless-v1-end-of-flaky-tests
https://github.com/godhiraj-code/waitless

[hanamichi77777]

I added an English description to the wiki.
https://github.com/hanamichi77777/WebDriverBiDi-via-VBA-test

[hanamichi77777]

I’ve updated the sample code（A_01_BiDi_Sample.bas）.
・All Japanese text has been removed.
・Enhanced logging to capture the unique XPath of elements triggering DOM mutations(See main01).
https://github.com/hanamichi77777/WebDriverBiDi-via-VBA-test

[hanamichi77777]

Using SendKeys in main03 is perfectly fine. However, note that the standard Click method for the Search button might fail if it gets hidden by autocomplete suggestions. Using ExecuteClickByXPath from the BiDi module bypasses this occlusion and correctly fires the click event.

[hanamichi77777]

【SeleniumVBA + WebDriver BiDi】Piercing Through Nested Frames in One Shot（See Main06）

Now, let's go ahead and check the "Import" radio button. Simple enough... or so you’d think.

Using the standard approach, the code would look like this. You are forced to navigate through the hierarchy using the SwitchToFrame method, drilling down layer by layer from the top level until you finally reach the target document. It’s quite a hassle.

driver.SwitchToFrame driver.FindElement(By.XPath,"//frame[@name='FR_M_INFO']")
driver.SwitchToFrame driver.FindElement(By.XPath,"//frame[@name='FR_DISP']")
driver.FindElement(By.XPath,"//input[@id='la_imp']").Click

With BiDi, however, as long as you know the URL of the internal frame, you can execute the click in just a single line.

bidi.ExecuteClickByXPath "//input[@id='la_imp']", , , , , bidi.GetIframeContextIdByUrl("jccht00d")

[hanamichi77777]

【SeleniumVBA + WebDriver BiDi】Direct Shadow DOM Targeting (Reference: Main 07)

Let’s try clicking the "Sign In" button on ServiceNow. As you might expect, it’s not exactly straightforward.

Using standard SeleniumVBA code, the process looks like this. You have to manually dive into each layer using the GetShadowRoot method until you reach the target document, which is quite a tedious task:

' Entry point of Shadow DOM
Set elm = driver.FindElement(By.TagName, "dps-app")

' Moving inside
Set elm = elm.GetShadowRoot.FindElement(By.TagName, "dps-navigation-header")

' Deeper inside
Set elm = elm.GetShadowRoot.FindElement(By.TagName, "sn-cx-navigation")

' Reaching the target (XPath cannot be used within Shadow DOM, so we use CssSelector)
Set elm = elm.GetShadowRoot.FindElement(By.cssSelector, "#utility-sign-in button")

' Finally, click Sign In
elm.Click

However, with WebDriver BiDi, you can reach and click the element in just a single line:

bidi.ExecuteShadowClick Array("dps-app", "dps-navigation-header", "sn-cx-navigation", "#utility-sign-in button")

Remarks
A common issue with the traditional GetShadowRoot approach is that it often lacks sufficient waiting logic, sometimes proceeding to the next step before the element is fully ready. I was forced to rely on 'On Error GoTo' as a workaround.

In contrast, the BiDi implementation ensures a stable execution by waiting reliably for the operation to complete.