Mozilla Hacksの「Puppeteer Support for the Cross-Browser WebDriver BiDi Standard」を読みました。この記事は、Puppeteerが次世代のブラウザ自動化標準であるWebDriver BiDiをサポートし、FirefoxとChromeを同じ標準プロトコルで扱える方向へ進んだことを紹介しています。
記事の要点
記事では、Puppeteer v21.6.0以降でFirefoxをWebDriver BiDi経由で起動できることが示されています。使い方としては、puppeteer.launchにproduct: 'firefox'とprotocol: 'webDriverBiDi'を指定する形です。同じwebDriverBiDiプロトコルをChromeでも使える点が、この話の重要な部分です。
背景には、Firefoxの従来のPuppeteer対応がChrome DevTools Protocol、つまりCDPの部分的な再実装に頼っていたという事情があります。CDPはChrome由来の強力な仕組みですが、ブラウザ横断の標準として設計されたものではありません。記事は、長期的にはWebDriver BiDiがFirefoxのリモート自動化の中心になるという見方を示しています。
参照先も確認したこと
元記事から、Puppeteer本体のドキュメント、WebDriver BiDi仕様、PuppeteerのWebDriver BiDiページ、Chrome DevTools Protocol、Mozilla Hacksのクロスブラウザテスト解説記事、pdf.jsのPuppeteerテスト移行PR、Chrome for Developers側の記事などを確認しました。
参照先まで見ると、これは「FirefoxでPuppeteerが動くようになった」という個別対応ではなく、テスト自動化の土台をブラウザ固有APIから標準仕様へ寄せる流れの一部だと分かります。Puppeteerの現在の説明でも、ChromeやFirefoxをDevTools ProtocolまたはWebDriver BiDiで制御するライブラリとして位置づけられています。
気づき
今回の気づきは、開発者体験の改善は新機能を足すことだけではなく、既存ツールの入口を標準へそろえることでも進むという点です。Puppeteerのように広く使われているツールがWebDriver BiDiへ対応すると、開発者は「ブラウザごとの自動化の癖」を直接扱う時間を減らせます。
もちろん、記事の時点ではWebDriver BiDi側に未対応機能もあります。Cookieストア、ネットワークインターセプト、一部のエミュレーションや権限まわりなどにはまだ差分があると説明されています。それでも、pdf.jsのテスト移行のような実例が出ていることから、標準化が机上の話ではなく、実際のテスト基盤を動かしながら進んでいることが見えてきます。
2024年のPuppeteer Firefox公式対応の記事とあわせて読むと、この2023年の記事はその前段にある重要な節目です。Firefox対応そのものよりも、ブラウザ自動化をCDP依存からWebDriver BiDiという共通の標準へ移していく設計判断として読むと、意味がかなりはっきりします。
コメントを残す