レガシープロトコルサポートの削除
カテゴリー
Selenium チームは、後方互換性を非常に重視していることを誇りに思っています。特に Java バインディングには、長年にわたって破壊的な変更がほとんどないように、多くの注意が払われてきました。15年前に書かれた Selenium コードが、Selenium 4 ライブラリで今でも実行できます！ これほどまでに優れたサポートを提供するには、大きなメンテナンス負担が伴いますが、ユーザーベースの大多数のニーズを適切に満たすことができる必要があります。
TL/DR
- レガシー JSON Wire Protocol のサポートは、Java Selenium 4.9 から削除されます（他の言語ではすでにこのサポートは削除されています）
- プロトコル変換は Selenium 4.9 Grid で停止します
- 非推奨の Desired Capabilities クラスの代わりに Browser Options クラス を使用することで、セッションが W3C 準拠であることを保証できます（また、「set capability」メソッドを直接使用することは避けてください）
- 現在のプロトコル変換機能に依存しており、それが正常に機能している場合は、Selenium Grid 4.8 で引き続き使用できます
過去7年間の Selenium 開発における最大の課題は、基盤となる実装をレガシー JSON Wire Protocol から新しい標準化された W3C WebDriver Protocol に移行することでした。 WebDriver 仕様が当時活発に開発されていたため、Selenium 3 は両方のプロトコルを同時にサポートしていました。 どちらのプロトコルを使用するかを決定するために「ハンドシェイク」コードを実装しました。 セッションを開始すると、Selenium は提供された capabilities をレガシー形式と W3C 形式の両方でパッケージ化し、ドライバー/サーバーに送信し、返されたプロトコルを使用します。 これはほとんどの場合うまく機能しました。 多くのユーザーにとって、新しいブラウザ（Firefox 47 以降および Chrome 75 以降）から W3C 準拠のセッションを取得するために変更は必要ありませんでした。
Java バインディングの場合、このアプローチをさらに一歩進めることが決定されました。 コードは、両方の形式で提供されたものをそのまま送信する代わりに、ユーザーに代わってレガシープロトコルから W3C プロトコルに capabilities を変換しました。 Selenium Grid はこのコードを利用しているため、どのクライアント言語がレガシー capabilities を送信しても、Grid はそれを W3C プロトコルに変換してドライバーとの通信を行い、結果をレガシープロトコルに再変換します。 コードが機能するためにはいくつかの仮定と推測を行う必要があるため、多くのフラストレーションのたまるエッジケースがあります。
Selenium 4.0 では、Ruby、JavaScript、および .NET バインディングはそれぞれハンドシェイクコードを削除したため、レガシーコマンドは使用されません。 3.x コードをフリーズする前に解決できなかったいくつかの問題により、Python は Selenium 4.9 までハンドシェイクコードを削除するのを待っています。 Selenium チームは、4.x リリース全体を通して Grid および Java バインディングで両方のプロトコルをサポートし続けるつもりでしたが、Selenium 4 Grid で Selenium 2 用に作成されたテストスイートを実行すると、予想よりも多くのエラーが発生しました。 多数のバグが発見され、中には大きな影響を与えるものもありました。
問題のコードは十分に複雑であるため、新しい問題を引き起こすことなくバグを修正することは大きな課題となります。 そのため、Selenium コードベースのいずれにおいても、レガシープロトコルからの capabilities とコマンドを明示的にサポートしないことで、コードベースを再び簡素化し始めることにしました。 最新バージョンの Java Selenium を使用している場合、削除される予定のものはすべてすでに非推奨とマークされているため、使用状況を再確認して、予期せぬ事態がないようにしてください。
この問題を調査して見つけた問題の詳細に興味がある場合は、Selenium Issue #10374 の議論をご覧ください。
Grid との互換性を確保するための詳細については、Selenium 4 アップグレードガイド に従ってください
