Playwright тестирует приложения в реальных браузерах: Chromium, WebKit и Firefox. Каждый из них предоставляет собственный движок рендеринга, интерпретации JavaScript и работы со шрифтами, мультимедиа и сетью. Поведение движков различается по мелким деталям: порядок выполнения микро- и макрозадач, реакция на события ввода, обработка layout-циклов и CSS-комбинаторики. Эти отличия становятся особенно заметны при мультиплатформенных прогонках, когда одно и то же тестовое действие приводит к разным DOM-состояниям или различным вариантам вычисленных стилей.
Выраженная полярность наблюдается у WebKit на macOS и iOS, где отдельные спецификации раскатываются с задержкой и требуют обходных CSS-решений. Firefox демонстрирует строгую интерпретацию стандартов и часто выявляет слабые места в асинхронной логике интерфейса. Chromium характеризуется агрессивными оптимизациями: предвычислением layout-метрик, спекулятивным выполнением JavaScript и упреждающим созданием рендер-слоев.
Различия браузеров усиливаются влиянием платформы. На Windows преобладают системные особенности ввода, хэндлинга IME и рендеринга шрифтов. На macOS заметно другое антиалиасинг-поведение и иная модель жестов. На Linux проявляются расхождения в зависимостях графической подсистемы (X11 против Wayland), которые затрагивают позиционирование окон и координатные преобразования.
Playwright учитывает эту неоднородность посредством собственного слоя абстракции. Тем не менее, тесты сталкиваются с вариативностью задержек при появлении UI-элементов, скоростью инициализации контекстов и моментом готовности страниц. Отличия проявляются также в работе сетевого стека: порядок применения CORS-проверок, кэширование, приоритизация запросов и размер TCP-окон нередко расходятся между платформами.
Ввод с клавиатуры и мыши на разных платформах реализован по-разному.
В macOS события клавиш зачастую сопровождаются системными
модификаторами, а в Windows клавиатурный фокус может переключаться иначе
при работе с виртуальными элементами. Linux в зависимости от оконного
менеджера способен генерировать дополнительные промежуточные события,
влияющие на частоту mousemove или wheel.
События касаний и жестов формируются по разным моделям. WebKit традиционно ориентирован на touch-интерфейсы iOS, где присутствуют дополнительные пассивные слушатели и особые правила отмены скролла. Chromium и Firefox на десктопных системах могут интерпретировать жесты как последовательности колесика мыши, что формирует собственные сценарии для тестов прокрутки.
Асинхронность рендеринга приводит к отличиям во времени появления
элементов. Chromium стремится быстро всплывать видимые ноды, тогда как
WebKit допускает паузы между расчетом layout и раскраской. Firefox
способен задерживать обновление стилей до ближайшего тика event loop.
Итогом становятся колебания таймингов, особенно в тестах, где
используется ожидание по visible или
enabled.
Селекторы в Playwright зачастую остаются устойчивыми ко многим
расхождениям, но отдельные CSS-вариации влияют на вычисление
псевдоклассов, такие как :focus-visible,
:hover и :active. Firefox может применять
:focus-visible более консервативно, WebKit на macOS склонен
раньше сбрасывать состояние :active, а Chromium приоритетно
расставляет ховер-состояния в условиях перекрытия элементов.
Системный рендеринг шрифтов не унифицирован. Windows использует
ClearType с уникальными характеристиками субпиксельного сглаживания,
macOS применяет собственную систему сглаживания и антиалиасинга, а Linux
делает выбор между Freetype и различными конфигурациями рендеринга в
зависимости от дистрибутива. Разница затрагивает не только визуальный
вывод, но и метрики: ширину глифов, кернинг и вычисленную высоту строки.
При вычислении boundingBox или clientHeight
для тестовой валидации результаты могут отличаться на несколько
пикселей.
Особенности GPU-акселерации и композитинга также вносят расхождения. Ядра Chromium склонны агрессивно поднимать элементы в отдельные слои, WebKit делает это избирательно, а Firefox опирается на собственный композитный стек. В результате тесты, связанные с анимациями и переходами, показывают разные моменты наступления стабильного состояния.
Playwright изолирует браузерные контексты, но сетевые факторы не полностью однородны. Кэширование, политика приоритизации HTTP/2, особенности TLS-стека и реализация HSTS могут отличаться между сборками браузеров и платформ. Chromium иногда выполняет preconnect и prerender, WebKit активнее использует предварительные DNS-запросы, Firefox аккуратно подходит к кэшированию и сверяет заголовки в условиях переадресаций.
Межпроцессная архитектура браузеров вносит дополнительную асинхронность. Chromium разделяет рендеринг, сеть и GPU по отдельным процессам, WebKit на macOS использует несколько уровней процессов WebContent, Firefox придерживается собственной многопроцессной модели. Это влияет на задержки при закрытии страниц, переключении вкладок и уничтожении контекстов.
Headless-режим не является точным зеркалом headful-режима. На разных
платформах рендеринг в headless может менять метрики шрифтов, иначе
рассчитывать размер окна и по-разному интерпретировать события ввода.
Например, WebKit headless в ряде сборок замещает часть графического
стека суррогатными реализациями, что влияет на вычисление
scrollHeight и clientWidth. Chromium headless
оптимизирует рендеринг в ущерб точности анимаций, а Firefox headless
может упрощать модель доступности.
Параметризация платформ и браузеров. Тестовая матрица с прогонками на Windows, macOS и Linux позволяет выявить расхождения в момент появления элементов, стабильности шрифтов и поведении прокрутки.
Работа с ожиданиями. Использование
locator.waitFor и ожиданий условий помогает сгладить
колебания таймингов. Жесткие задержки (waitForTimeout)
приводят к неустойчивым результатам и плохо переносятся между
платформами.
Терпимость к пиксельным расхождениям. Скриншотные тесты рекомендуется настраивать по порогу сравнения. Идеальная идентичность кадров на разных системах почти недостижима из-за различий сглаживания шрифтов и композитинга.
Аккуратное использование состояния ввода. Важно
учитывать, что клавиатурный фокус и hover-статусы меняются по различным
правилам. Лучше полагаться на focus() и методы симуляции
событий Playwright, чем на предположения о поведении платформы.
Понимание headless-особенностей. Различия рендеринга и событийной модели в headless часто проявляются в micro-UI: скролл, прокрутка, всплывающие popover-элементы. Тесты, опирающиеся на эти подвижные элементы, предпочтительно запускать также в headful.
Поведение браузеров неоднородно как на уровне движков, так и на уровне платформ. Различия выражены в событиях ввода, сетевой модели, рендеринге шрифтов, композитинге и таймингах обновления DOM. Playwright не устраняет различия, но предоставляет инструменты, позволяющие сделать тесты устойчивыми: контексты, ожидания, селекторы, headless/headful режимы и конфигурацию матрицы прогонов.