WebDriver BiDi

Klasyczny WebDriver opiera się na modelu żądanie–odpowiedź w protokole HTTP. Tester wysyła komendę (click, findElement), przeglądarka zwraca wynik i sesja czeka na kolejny krok. W tym układzie przeglądarka nie może zainicjować kontaktu – nie przekaże informacji o starcie żądania sieciowego ani o wyjątku JavaScript. Do obsługi tych zdarzeń (przechwytywanie ruchu, logi konsoli, błędy JS) przez lata wykorzystywano Chrome DevTools Protocol. CDP działa niskopoziomowo i szybko, jednak ogranicza się do silnika Chromium i nie posiada statusu oficjalnego standardu. 

WebDriver BiDi eliminuje to ograniczenie. Łączy niezależność od dostawcy przeglądarki ze strumieniowym przesyłaniem zdarzeń do klienta za pomocą protokołu WebSocket. Pozwala to przeglądarce na wysyłanie powiadomień w czasie rzeczywistym, bez konieczności ciągłego odpytywania jej przez skrypt testowy.

WebDriver BiDi a CDP 

Utożsamianie WebDriver BiDi z ustandaryzowaną wersją CDP to powszechny błąd. Zrozumienie różnic między nimi pozwala właściwie ocenić obecne i przyszłe ograniczenia nowego protokołu. 

CDP powstał na potrzeby Chrome i jest ściśle powiązany z kodem źródłowym Chromium. Przeglądarki takie jak Firefox czy te oparte na silniku WebKit mają inną architekturę, co uniemożliwia im bezpośrednie wdrożenie metod CDP. Grupa robocza W3C świadomie odrzuciła więc koncepcję kalkowania rozwiązań Google. BiDi powstaje wokół realnych potrzeb automatyzacji, a nie na bazie kodu jednego silnika. 

Z tego samego powodu BiDi nie ma na starcie wszystkiego, co oferuje CDP. Wynika to z konieczności pogodzenia trzech rozbieżnych priorytetów:

• wydajności sieciowej – CDP operuje lokalnie, a BiDi musi działać stabilnie również w infrastrukturze rozproszonej, redukując komunikację na linii klient–serwer. Dlatego BiDi zwraca identyfikator i wartość obiektu w ramach jednej odpowiedzi, eliminując dodatkowe zapytanie wymagane przez CDP, 
• przystępności – zbyt wysoki poziom skomplikowania specyfikacji utrudnia implementację protokołu w przeglądarkach i narzędziach testowych, 
• uniwersalności silników – każde rozwiązanie, jak choćby mechanizm retencji obiektów JavaScript do celów debugowania, musi dać się efektywnie zaimplementować jednocześnie w Chromium, Gecko i WebKit. 

To właśnie te kryteria decydują o nierównomiernym tempie wdrażania poszczególnych opcji w przeglądarkach. 

Struktura modularna i model subskrypcji

Architektura WebDriver BiDi opiera się na modułach odpowiadających konkretnym obszarom automatyzacji. Z perspektywy inżynierii testów znaczenie mają:

• browsingContext – zarządzanie oknami, kartami oraz elementami typu iframe (w tym nawigacja, tworzenie i zamykanie kontekstów, zrzuty ekranu oraz generowanie plików PDF),
• script – ewaluacja kodu JavaScript, serializacja danych oraz konfiguracja skryptów typu preload, uruchamianych przed załadowaniem struktury strony, 
• network – rejestracja zdarzeń sieciowych (żądań i odpowiedzi), inspekcja ruchu oraz obsługa mechanizmów uwierzytelniania, 
• input – emulacja interakcji użytkownika (mysz, klawiatura) oraz obsługa pól przesyłania plików, 
• log – przechwytywanie logów konsoli oraz wyjątków zgłaszanych przez silnik JavaScript. 

Warstwą nadrzędną dla tych modułów jest model subskrypcji. Klient definiuje typy zdarzeń, które zamierza monitorować, a przeglądarka przesyła je asynchronicznie w momencie ich wystąpienia. Rozwiązanie to zastępuje klasyczny polling ze starszego protokołu, wymagający cyklicznego odpytywania struktury DOM w pętli w celu wykrycia zmian. 

Zastosowania

Scenariusze zdefiniowane w oficjalnej specyfikacji projektowej protokołu określają bezpośrednie obszary wdrożeń w codziennej automatyzacji.

Rejestracja logów konsoli i wyjątków JS

Subskrypcja modułu log umożliwia przechwytywanie wpisów console.log() oraz nieobsłużonych wyjątków środowiska wykonawczego w czasie rzeczywistym. Pozwala to na implementację wzorca, w którym błąd w konsoli automatycznie przerywa wykonywanie testu, eliminując problem pomijania awarii interfejsu. 

Manipulacja ruchem sieciowym

Protokół umożliwia inspekcję żądań i odpowiedzi, modyfikację nagłówków, metod, statusów oraz treści komunikatów. Pozwala także na blokowanie zasobów i serwowanie odpowiedzi testowych (mockowanie), co w pełni zastępuje dotychczasowe skrypty oparte na CDP.

Automatyzacja uwierzytelniania

Obsługa wyzwań HTTP Auth (Basic, Digest) pozwala na programowe przekazywanie poświadczeń bezpośrednio do silnika przeglądarki, z pominięciem natywnych okien dialogowych. 

Inicjalizacja skryptów startowych (preload)

Wstrzykiwanie kodu przed rozpoczęciem ładowania struktury dokumentu pozwala na wczesną konfigurację obserwatorów DOM lub nadpisywanie obiektów API aplikacji. 

Emulacja środowiska

Kontrola nad geolokalizacją, strefami czasowymi, wymiarami ekranu urządzeń mobilnych oraz symulacją braku łączności. Wolniejsze tempo wdrażania tych funkcji przez długi czas ograniczało pełną migrację na BiDi we frameworkach takich jak Playwright (przykłady omówiono tutaj i tutaj). 

Izolacja kontekstów użytkownika 

Moduł browsingContext pozwala na zarządzanie wieloma oknami i kartami w ramach jednej sesji, a odrębne profile użytkowników (user context) gwarantują niezależne pule ciasteczek i pamięci podręcznej. Ułatwia to automatyzację scenariuszy wielozadaniowych, np. testu komunikatora między dwoma zalogowanymi użytkownikami, przy czym subskrypcję zdarzeń można zawęzić do jednego, wybranego profilu. 

Realna dostępność funkcji

Implementacja standardu rzadko nadąża za intencjami jego twórców. WebDriver BiDi nadal funkcjonuje jako W3C Working Draft z ostatnią aktualizacją z czerwca 2026 roku. Architektura API stale się rozwija, co skutkuje zmianami w sygnaturach metod nawet w drobnych aktualizacjach. To wymusza na zespołach deweloperskich stałą kontrolę nad wersjami bibliotek i dokładną analizę dokumentacji wydań. 

Natywne wsparcie deklarują dziś Chrome, Edge i Firefox. Diabeł tkwi jednak w szczegółach technicznych, a dojrzałość rozwiązań zależy od wybranego języka i silnika. Najbardziej miarodajny wskaźnik gotowości technologicznej stanowią raporty dostępne w serwisie wpt.fyi. Pokazują one rzeczywisty stan przejścia testów i ujawniają sytuacje, w których funkcja stabilna w Google Chrome generuje błędy krytyczne w środowisku Mozilla Firefox. 

Po stronie narzędzi obraz na połowę 2026 wygląda następująco:

Historia Puppeteera pokazuje, jaką lukę technologiczną wypełnia nowy standard. Przed wejściem BiDi obsługa Firefoxa w tym narzędziu zależała od niekompletnej adaptacji CDP tworzonej przez Mozillę. Protokół BiDi zunifikował mechanizmy kontroli nad Chrome i Firefoxem. W przypadku silnika Chromium, Puppeteer świadomie pozostaje jednak przy CDP, chroniąc stabilność wdrożonych automatyzacji i unikalne funkcje deweloperskie Chrome.

Narracja o całkowitym przejściu Selenium na BiDi bywa myląca. Protokół ten funkcjonuje tam jako komponent dopasowany do tradycyjnego fundamentu HTTP. Dopiero wersja Selenium 5 ma przynieść pełne, wysokopoziomowe API ukrywające te zawiłości konstrukcyjne pod prostszymi interfejsami.

O użyteczności standardu decyduje jednak stabilność w potokach CI i architekturze zdalnej. Usługi takie jak BrowserStack oferują już produkcyjną obsługę żądań i zdarzeń BiDi w środowisku wieloprzeglądarkowym. Odpowiedzią po stronie open-source jest Selenium Grid w wersji 4.41.0 (luty 2026), który dzięki natywnej obsłudze WebSocketów sprawnie pośredniczy w dwukierunkowej komunikacji. W efekcie zdalne przechwytywanie ruchu sieciowego staje się standardem, a nie technicznym wyzwaniem – chociaż końcowy sukces operacji wciąż zależy od konfiguracji środowiska i wersji bibliotek.

Ograniczenia BiDi

Nowy standard nie przejmuje wszystkich ról CDP. Debugowanie wewnętrznych mechanizmów Chromium w DevTools wciąż wymaga stosowania protokołu od Google. BiDi projektowano z myślą o inżynierii testów, a nie o pełnej diagnostyce silnika renderującego. 

Pojawienie się nowego standardu nie eliminuje z rynku istniejących frameworków. Narzędzia takie jak Puppeteer czy Playwright zachowują swoją pozycję, zyskując dzięki BiDi natywną wieloprzeglądarkowość. Najbardziej radykalną strategię przyjął Firefox. Mozilla wyłączyła już domyślną obsługę CDP i dąży do jej całkowitego usunięcia, uznając WebDriver BiDi za jedyny docelowy protokół zdalnej kontroli nad przeglądarką.

Podsumowanie

Status "przyszłości automatyzacji" często zniekształca realny obraz możliwości WebDriver BiDi, przypisując mu cechy, których ten protokół nie posiada. Nowy standard modyfikuje ściśle określone obszary: przechwytywanie ruchu sieciowego, obsługę zdarzeń i dostęp do konsoli. Wyzwania, które generują największy koszt utrzymania testów, pozostają nienaruszone. Słaby, podatny na zmiany selektor spowoduje awarię testu niezależnie od tego, czy komunikacja z przeglądarką idzie po HTTP, czy po WebSockecie. Podobnie asynchroniczność aplikacji frontendowej będzie dalej źródłem niestabilności, jeśli skrypty nie posiadają prawidłowych mechanizmów oczekiwania.

Zamiast oceniać BiDi jedynie przez pryzmat nowoczesności, lepiej przeanalizować architekturę własnych testów. Protokół przynosi korzyść tam, gdzie automatyzacja wymagała dotąd sięgania po CDP lub konfiguracji serwerów proxy do symulowania odpowiedzi sieciowych. Nie wpłynie on jednak na poprawę stabilności testów wynikającą ze złych praktyk implementacyjnych czy częstych zmian w kodzie źródłowym interfejsu. Ostatecznym punktem odniesienia pozostają zestawienia wyników na wpt.fyi oraz szczegółowe wykazy zmian w kolejnych wersjach narzędzi.