Roadmap

Roadmap & Future Development

This page outlines the current development focus and the long-term vision for osn-selenium. The project aims to push the boundaries of what is possible with Selenium by moving towards a high-performance, protocol-native architecture.

---

1. True Asynchronicity (Experimental Architecture)

Status: Beta Release (v1.2.0-beta.0)

TWe have successfully introduced the BiDi Mapping architecture (trio_bidi). This architecture eliminates the thread-pool overhead by using a direct WebSocket connection.

Current Capabilities:

• Direct Communication: Standard Selenium commands are translated to BiDi and executed over WebSockets.
• Connection Pool: A robust BiDiConnectionPool manages task routing and responses.
• Context Management: Native use_context allows controlling multiple tabs simultaneously in one task loop.

Next Steps:

• Full Coverage: Expanding mapping to cover 100% of W3C specs (currently experimental).
• Input Domain: Fully integrating BiDi Input domain for native mouse/keyboard events (currently using JS hooks for some interactions).

Why this matters:

This architecture allows for true parallel execution within a single browser instance. You will be able to trigger multiple actions (e.g., searching for elements in one tab while navigating in another) simultaneously without any cross-thread blocking.

Plan: Gradual integration, starting with high-frequency methods like get(), switch_to(), and find_elements().

---

2. Versioned DevTools Domains

Status: In Development

Currently, the dev_tools package domains are statically tied to the framework version. We are updating the osn-selenium-package-parser to generate not just raw CDP classes, but entire functional dev_tools domain packages.

• Decoupling: DevTools logic will move out of the core framework and into versioned packages hosted at osn-selenium-cdp.
• Total Compatibility: This ensures that advanced features (like Request Interception) work flawlessly regardless of which Chromium version you are running.

---

3. Hybrid Composition

Status: Not Started

To provide more flexibility in coding styles, we plan to implement a hybrid access model. While the current Mixin-based "flat" structure is excellent for debugging, we will add namespaced accessors.

• Current: driver.get_window_rect()
• Planned: driver.window.get_rect() or driver.navigation.get() This allows developers to choose between the flat Selenium-like API and a more organized, grouped API.

---

4. Advanced HM Interaction Presets

Status: Not Started

The Human-like (HM) movement engine will be opened up for deeper customization:

• Custom Algorithms: Interfaces to plug in your own mathematical models for mouse movement and typing.
• Behavioral Presets: Pre-configured profiles (e.g., "Fast Typer", "Lazy Scroller", "Mobile Touch User") to vary automation behavior across different sessions.

---

5. Browser Family Expansion

Status: Not Started

While Chromium/Blink is the current priority, we aim to expand the framework to:

• Gecko Driver: Full support for Firefox using the same Mixin architecture.
• Extended Chromium: Specialized support for other engines like Brave or Opera.

---

6. macOS Support

Status: Not Started

Currently, the library supports Windows and Linux (via browsers_handler). We plan to implement macOS-specific detection logic (scanned via /Applications and plist parsing) to make the library truly universal.

---

[TIP] If you are interested in contributing to the experimental BiDi-bridge or testing new HM presets, please check our GitHub Issues or join the discussion.