Selenium协议与W3C WebDriver标准的关系及相关技术疑问

Hey there! Let's break down all your questions about Selenium, the W3C WebDriver standard, and ChromeDriver clearly—this stuff can get tangled, but we'll unpack it step by step.

1. Differences between Selenium's legacy protocol and the W3C WebDriver Standard, plus convergence #

• Legacy Selenium Protocol: Before the W3C standard, Selenium used the JsonWireProtocol (a custom REST API) to communicate between test code and browser drivers. It had its own endpoints, request/response formats, and ecosystem-specific quirks.
• W3C WebDriver Standard: This is a universal, browser-agnostic protocol defined by the W3C to standardize browser automation. It specifies consistent commands, data formats, and behaviors across all compliant browsers (Chrome, Firefox, Edge, etc.).
• Convergence: Yes, they’re fully converged now. Modern Selenium versions (3.11+) default to the W3C WebDriver protocol. The JsonWireProtocol is deprecated, only maintained for backward compatibility with older drivers. Selenium now acts as a wrapper aligned with the W3C spec.

2. Is WebDriver built into browsers? Why do we need ChromeDriver instead of connecting directly to Chrome? #

• WebDriver isn’t directly exposed by browsers: Browsers have internal automation APIs, but these aren’t accessible directly from external apps for security and stability reasons—exposing them would create major security risks (like arbitrary code execution).
• ChromeDriver's role: It acts as a secure bridge between your automation code (or Selenium) and Chrome. It translates W3C commands into Chrome’s internal instructions, handles browser startup/shutdown, manages session isolation, and enforces security boundaries. Without it, there’s no standardized, safe way to send commands to Chrome.

3. Is Selenium Server just a pure proxy? Does it use the W3C API? #

• No, it’s more than a proxy: While it forwards commands to browser drivers, it also provides critical functionality like:
  • Session management and isolation across multiple test runs
  • Support for Selenium Grid (distributed testing across browsers/machines)
  • Protocol translation for older drivers still using the legacy JsonWireProtocol
  • Log aggregation and structured error reporting
• W3C support: Modern Selenium Server fully implements the W3C WebDriver API. It receives W3C-compliant requests, validates them, and forwards them to compliant browser drivers like ChromeDriver.

4. How to communicate directly with browsers using a lightweight W3C-compliant layer? Is controlling a remote headless Chrome as simple as proxying requests to its server? #

• Direct browser communication via W3C: You don’t need Selenium—send raw HTTP requests directly to a W3C-compliant browser driver (like ChromeDriver):
  1. Start ChromeDriver locally: chromedriver (it listens on port 9515 by default)
  2. Send a POST request to create a headless session:

     curl -X POST http://localhost:9515/session \
       -H "Content-Type: application/json" \
       -d '{"capabilities": {"alwaysMatch": {"browserName": "chrome", "goog:chromeOptions": {"args": ["--headless"]}}}}'
     

  3. Use the returned session ID to send commands like navigating to a URL or clicking elements.
• Remote headless Chrome: It’s nearly that simple, but you need to run ChromeDriver on the remote server (not just Chrome). The remote ChromeDriver manages the headless instance, and your lightweight layer sends W3C requests directly to its address (e.g., http://remote-server-ip:9515/session). No Selenium Server is required unless you need to manage multiple remote drivers (that’s where Selenium Grid comes in).

5. Can we fully replace Selenium with a custom implementation based on the W3C standard? How? What features would we lose? #

• Yes, you can: The W3C WebDriver standard is self-contained, so you can build your own automation tool by sending raw HTTP requests to browser drivers.
• How to do it:
  1. Pick a W3C-compliant driver (ChromeDriver, GeckoDriver for Firefox, etc.).
  2. Use an HTTP client (like Python’s requests, JavaScript’s fetch, or curl) to send requests following the W3C spec (create sessions, find elements, execute commands).
  3. Handle response parsing, session management, and error handling manually.
• Features you’d lose:
  • High-level API abstractions: Selenium provides ready-to-use methods like find_element(By.ID, "foo") or WebDriverWait—you’d have to build all these yourself with raw W3C commands.
  • Cross-browser compatibility: Selenium abstracts browser-specific quirks; with a custom implementation, you’d need to handle these differences directly.
  • Test framework integration: Selenium works seamlessly with pytest, JUnit, or TestNG—you’d have to build your own integration layer.
  • Selenium Grid support: Managing distributed testing across multiple browsers/machines would require building your own orchestration system.
  • Advanced features: File upload handling, simplified cookie management, and screenshot capture are wrapped nicely in Selenium—you’d have to code these from scratch.

Bonus: Can we run ChromeDriver directly and connect to it? #

Absolutely! ChromeDriver is officially published by Google. Download the version matching your Chrome browser, run the chromedriver binary, and it will listen on port 9515 by default. You can send W3C-compliant HTTP requests directly to that port to control Chrome, just like the example above.

内容的提问来源于stack exchange，提问作者Merc