Политика Device Pixel Ratio с --bot-dpr

Политика коэффициента пикселей устройства относится к отображению, а не к настройке рендеринга: MacBook Retina сообщает 2 в window.devicePixelRatio, обычный рабочий ноутбук обычно 1 или 1.25, и профиль, подготовленный для одного из них, не должен молча наследовать значение другого. BotBrowser предоставляет --bot-dpr с режимами profile, real и advanced, чтобы источник этого числа был записан в командной строке, а адаптивный CSS страницы и использование значения сайтом оставались делом сайта.

Для отдельного вопроса жизненного цикла смотрите эмуляцию активного окна и состояние видимости.

TL;DR

• --bot-dpr=profile используется по умолчанию: берётся масштаб отображения профиля, поэтому DPR, окно и экран остаются согласованными, если дополнительно задать --bot-window=profile и --bot-screen=profile.
• --bot-dpr=real следует за монитором хоста, что подходит оператору поддержки или дизайн-ревью, где экран рабочей станции и есть нужный опыт.
• advanced сохраняет DPR профиля и применяет ограниченные правки макета; он экспериментальный, по умолчанию не включён и не является режимом повышенной точности.
• Выбирайте режим до того, как BrowserContext создаст первую страницу или worker, потому что существующие страницы сохраняют поведение, установленное при запуске их контекста.
• Записывайте пять полей рядом с каждым запуском: версия BotBrowser, профиль, режим DPR, область просмотра и цель снимка.

Содержание

• Почему масштаб дисплея важен для страницы
• Три режима: profile, real и advanced
• Согласованность DPR с окном и экраном
• Поконтекстные сессии
• Проверка и фиксация политики
• Внедрение и сопровождение политики

Смотреть видео

Это видео на английском следует за одним числом, window.devicePixelRatio. Оно разбирает обычные значения из статьи и три режима (profile, real и advanced), а затем спрашивает у настоящего браузера, откуда берётся его собственное число: локальная лабораторная страница читается в консоли DevTools обычного Chrome на runner Ubuntu (DPR 1 на экране 1920 на 984; запрос 2dppx не совпадает), а на runner Windows интерфейс DevTools масштабируется с 1,25 до 1,75, то есть это собственный масштаб инструмента, а не страницы. В конце - правило для отдельного контекста и пять полей, которые стоит записывать рядом с каждым запуском. В записях не загружен ни один профиль BotBrowser, поэтому режимы --bot-dpr цитируются из этой статьи, а не запускаются. Аудио на английском.

Почему масштаб дисплея важен для страницы

window.devicePixelRatio сообщает странице, сколько физических пикселей приходится на один CSS-пиксель. Офисный ноутбук обычно сообщает 1 или 1.25, MacBook с Retina сообщает 2, а многие телефоны сообщают 3. Это же значение участвует в медиазапросах разрешения CSS, выборе адаптивных изображений и расчётах макета, поэтому оно связано с остальной конфигурацией дисплея: размером экрана, размером окна и глубиной цвета.

Когда профиль описывает один дисплей, а монитор хоста другой, сессия несёт сразу две конфигурации дисплея. Параметр --bot-dpr делает этот выбор явным, а не отдаёт его на усмотрение машины, на которой случайно запущен браузер. BotBrowser может явно задавать соотношение пикселей устройства для профиля в контролируемом контексте, но не может изменить то, как сайт реагирует на это значение.

В обычном браузере значение не всегда постоянно. MDN отмечает, что оно меняется, когда пользователь масштабирует страницу, а во многих настольных конфигурациях меняется и при перемещении окна на монитор с другим масштабом. Страница может отслеживать такие изменения через медиазапрос разрешения, поэтому приложение способно перерисовать изображения или холсты после обновления значения. Для воспроизводимого сценария это важно на практике: сессия с одним зафиксированным и документированным источником масштаба дисплея даёт странице стабильное начальное значение, и последующее различие между запусками указывает на страницу или хост, а не на незафиксированную настройку дисплея.

Страницы читают DPR не изолированно. Запросы разрешения CSS могут выбирать другую таблицу стилей при изменении масштаба. Адаптивные изображения могут выбирать другой источник. Размеры холста, расчёты визуального вьюпорта и элементы масштабирования приложения тоже могут зависеть от соотношения CSS-пикселей и физических пикселей.

Мобильные профили обычно используют больший DPR, чем десктопные. Важно не то, что большее число лучше. Важно, чтобы значение соответствовало предполагаемому семейству устройств и размерам экрана из того же профиля. Не переносите DPR мобильного устройства в десктопный профиль только ради того, чтобы страница выбрала изображение с более высоким разрешением.

Три режима: profile, real и advanced

Режим	Когда использовать	Результат
profile	Конфигурацию дисплея должен определять профиль	Используется масштаб дисплея профиля. Значение по умолчанию.
real	Сессия должна следовать дисплею хоста	Используется масштаб дисплея хоста.
advanced	Существующему сценарию нужна ограниченная корректировка макета при сохранении DPR профиля	Экспериментальный режим совместимости. По умолчанию не включён.

profile используется по умолчанию, поэтому существующие запуски сохраняют своё поведение. Задавайте другой режим только тогда, когда это нужно развёртыванию.

Начните с модели дисплея, которую должен представлять профиль. Браузер на основе профиля обычно несёт целевую операционную систему, семейство вьюпорта, размеры экрана и возможности ввода. Масштаб дисплея относится к той же группе. Если профиль представляет ноутбук или телефон, profile сохраняет связь масштаба с остальными данными профиля.

Используйте real для рабочей станции, где физический монитор является частью пользовательского опыта. Это обычная ситуация для оператора поддержки, дизайн-ревью или сессии браузера, которая должна следовать настройкам доступности на хосте. В таких случаях источником истины служит дисплей хоста. real раскрывает масштаб дисплея хоста, который может отличаться от выбранного профиля, поэтому выбирайте его только тогда, когда такая конфигурация на основе хоста задумана намеренно.

advanced экспериментален и по умолчанию не включён. Он сохраняет DPR профиля и применяет ограниченные корректировки макета, но не масштабирует всю страницу заново и не гарантирует совпадения измерений макета или скриншотов. Это не режим повышенной точности, и сама по себе разница между DPR хоста и профиля не повод его включать. Перед внедрением проверьте затронутый макет страницы и скриншоты на нужном хосте и вернитесь к profile, если корректировки вносят несогласованность.

Настольные системы могут работать с мониторами, у которых разные настройки масштаба. Хост может сообщать одно значение, тогда как профиль подготовлен для другого. profile удобен, когда профиль должен оставаться стабильным на разных машинах. real удобен, когда дисплеем должна управлять текущая рабочая станция. Оба варианта допустимы и опираются на разные источники истины.

Согласованность DPR с окном и экраном

DPR, окно и экран образуют одну конфигурацию дисплея. Меняйте их вместе, а не по одному между запусками.

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --bot-dpr=profile \
  --bot-window=profile \
  --bot-screen=profile

Десктопные сессии с интерфейсом по умолчанию используют размеры окна и экрана хоста. Если сессия с интерфейсом должна сообщать размеры профиля, задайте --bot-window=profile и --bot-screen=profile рядом с --bot-dpr=profile. Руководство по экрану и окну описывает параметры размеров, а эмуляция устройств описывает мобильные профили.

Сессия рабочей станции, которая представляет собственный монитор оператора, может вместо этого использовать дисплей хоста для всех трёх значений:

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --bot-dpr=real \
  --bot-window=real \
  --bot-screen=real

Точные значения окна и экрана зависят от профиля и развёртывания. Два примера показывают связь между тремя политиками. Выбирайте значения, которые поддерживает установленная сборка BotBrowser, и сохраняйте один и тот же набор для сравниваемых страниц.

Развёртывания без интерфейса требуют такой же дисциплины. Без видимого монитора источник дисплея всё равно остаётся выбором: решите, представляет ли сессия дисплей профиля или дисплей хоста, и задавайте параметры явно, а не наследуйте то, что предоставляет машина.

Когда сессия переходит с локальной рабочей станции на удалённую машину, решите, представляет ли браузер дисплей оператора или целевой дисплей профиля. Сделайте это решение частью конфигурации развёртывания. Не выбирайте режим по переменной окружения, которая незаметно меняется между машинами. Явный аргумент запуска упрощает аудит получаемого поведения. Локальный тест с real может дать другой результат на машине без физического монитора, а тест с profile может отличаться от теста на рабочей станции, привязанного к монитору. Ни один из результатов не ошибочен, но разница должна быть намеренной.

Поконтекстные сессии

При поконтекстных отпечатках задавайте --bot-dpr до того, как BrowserContext создаст первую страницу или worker. Выбранная политика остаётся связанной с поведением дисплея и макета этого контекста. Существующие страницы сохраняют поведение, заданное при старте их контекста, поэтому последующее изменение команды запуска их не обновляет. Закройте и создайте контекст заново, когда конфигурация дисплея должна измениться.

Используйте один режим для основного браузера и поконтекстного профиля, когда они представляют одно и то же устройство. Выбирайте другой режим, только если контекст намеренно представляет другую среду дисплея. Масштабирование контекстов браузера описывает более широкий жизненный цикл контекстов.

Если несколько контекстов представляют одно семейство устройств, используйте одну политику DPR и согласованные настройки окна и экрана. Если они намеренно представляют разные устройства, храните настройки каждого контекста вместе в его собственной записи конфигурации. Не делите один контекст между дисплеем на основе профиля и дисплеем на основе хоста, если приложение зависит от стабильного адаптивного макета.

Пулы контекстов тоже должны фиксировать выбранный режим. Это помогает объяснить, почему две страницы с одним URL могут получить разную адаптивную разметку, и не даёт worker унаследовать контекст, созданный для другой политики дисплея.

Сервис, который запускает много контекстов, должен задавать режим в общей конфигурации запуска и копировать его в параметры создания каждого контекста. Записывайте выбранный режим в журнал при старте, не записывая содержимое профиля. Держите одного ответственного за значения командной строки по умолчанию, которые используют обёртки и сервисы запуска. Если несколько скриптов выбирают собственные значения по умолчанию, изменение при сопровождении может разделить пул контекстов на разные политики дисплея.

Когда обёртка строит командную строку, передавайте выбранный режим целым значением, а не склеивайте непроверенный текст. Принимайте только profile, real и advanced и отклоняйте любое другое значение до запуска браузера. Неудавшийся запуск проще диагностировать, чем сессию, которая молча использует другую политику дисплея.

Проверка и фиксация политики

1. Запустите сессию с выбранным профилем и одним режимом DPR.
2. Не меняйте окно, экран и DPR на протяжении всей проверки.
3. Запустите вторую сессию с тем же профилем и режимом и убедитесь, что поведение дисплея совпадает.
4. При сравнении режимов меняйте только --bot-dpr и фиксируйте полную команду запуска для каждого прогона.

Проверка отпечатка браузера перечисляет публичные проверки, которые показывают сообщаемые значения дисплея.

Ситуация	Действие
Ожидается поведение дисплея профиля	--bot-dpr=profile
Сессия должна следовать дисплею хоста	--bot-dpr=real
Существующему сценарию нужна корректировка макета	Оцените экспериментальный --bot-dpr=advanced на нужном хосте, иначе оставьте profile
Дисплей различается между контекстами	Задайте режим до того, как каждый контекст создаст страницы или worker
Размеры с интерфейсом следуют хосту	Добавьте --bot-window=profile и --bot-screen=profile

Полное описание параметра приведено в справочнике параметров CLI.

Ведите краткую запись для каждого прогона. Поля, которые объясняют большинство различий масштаба дисплея, это версия BotBrowser, профиль, режим DPR, вьюпорт и цель захвата, например скриншот, PDF или измерение страницы. По этим пяти полям проверяющий понимает, чем различаются два захвата: политикой, профилем или способом получения результата, и ему не нужно заново открывать страницу.

Чтобы сравнить режимы на одной странице, запустите один и тот же сценарий три раза с одинаковыми версией браузера, профилем, вьюпортом, режимом окна и режимом экрана, меняя между запусками только --bot-dpr. Сохраняйте команду запуска рядом с каждым результатом. Если два прогона различаются, сохранённые команды сразу показывают, был ли режим единственным изменением, а если не различаются, страница в этом сценарии не зависит от масштаба дисплея.

Размеры скриншота выражаются в CSS-пикселях, тогда как итоговое растровое изображение может зависеть от коэффициента масштабирования устройства. Тест, который сравнивает изображения, должен держать режим DPR неизменным и для эталонного, и для текущего захвата. Иначе макет может остаться прежним, а размеры изображения или растеризация текста будут отличаться.

У сценариев PDF и печати есть собственные правила размера страницы, но веб-макет, который питает печать, по-прежнему зависит от значений вьюпорта и дисплея. Выберите политику DPR до загрузки документа и держите параметры печати отдельно от параметров дисплея. Так проще отличить изменение CSS-макета от изменения размера бумаги.

Для визуальной регрессии храните политику рядом с вьюпортом и версией браузера в метаданных теста. Пересоздавайте эталон только тогда, когда меняется намеренная политика дисплея. Не обновляйте скриншоты только потому, что у исполнителя другой монитор. Используйте profile для переносимых эталонов или real для тестов, явно привязанных к рабочей станции.

Перед выпуском конфигурации убедитесь в записи запуска, что:

• версия BotBrowser зафиксирована;
• цель профиля и роль хоста задокументированы;
• режим DPR задан явно;
• режимы окна и экрана заданы явно;
• режим задан до создания первой страницы;
• тесты скриншотов и адаптивности используют ту же политику, что и их эталон;
• конфигурация каждого контекста фиксирует собственную политику дисплея;
• переход с profile на real или advanced рассматривается как изменение поведения.

Эти проверки не требуют, чтобы страница раскрывала приватные данные профиля. Они делают источник поведения дисплея понятным для команды, которая эксплуатирует браузер. Если макет отличается после развёртывания, запись запуска подсказывает, с чего начать сравнение.

Внедрение и сопровождение политики

Начните с одного показательного профиля и одного прикладного сценария. Выполните сценарий с profile, затем повторите его с той же версией браузера, вьюпортом и настройками окна. Если дисплей хоста входит в требования, повторите сравнение с real. Храните результат каждого прогона вместе с записью запуска. Так у команды появится небольшой набор эталонов до применения политики к большому пулу.

Сначала внедрите выбранный режим в одной группе контекстов. Проверьте страницы с адаптивной навигацией, выбором изображений, таблицами, графиками и макетами печати, потому что эти области часто показывают изменения дисплея раньше обычных текстовых страниц. Если результат подходит, примените ту же конфигурацию к остальным контекстам, которые представляют то же семейство устройств.

Рассматривайте выбранный режим как часть входных данных теста, а не как деталь окружения. Когда в отчёте об ошибке сказано, что страница выглядела иначе, первый вопрос в том, какой источник дисплея использовала сессия. Если запись запуска отвечает на него, расследование сразу переходит к странице, профилю или хосту.

Не смешивайте изменение политики со сменой версии браузера, миграцией профиля или переработкой вьюпорта. Каждое из этих изменений может повлиять на поведение макета. Когда нужно несколько изменений, применяйте их в отдельных тестовых прогонах и ведите отдельные записи. Чёткая последовательность позволяет понять, какое изменение повлияло на результат.

После перехода на новый выпуск BotBrowser пересмотрите выбранную политику, даже если командная строка не менялась. Значением по умолчанию остаётся profile, но выпуск может изменить доступную документацию или поддерживаемые параметры. Используйте тот же профиль и те же параметры захвата для сравнения до и после. Если результат изменился, проверьте в таком порядке версию браузера, профиль, режим окна, режим экрана и режим DPR.

Храните версию браузера, профиль, выбранный режим, вьюпорт и цель захвата рядом с конфигурацией теста или сервиса. Эта запись полезна, когда страница меняет адаптивный макет, когда меняется источник изображения или когда скриншот получается неожиданного размера. Она также даёт проверяющим конкретный список значений для утверждения перед внедрением.

Настройки дисплея хоста могут влиять на размер текста, контраст и поведение ввода на рабочей станции с интерфейсом. Если оператор работает с браузером напрямую, real может соответствовать его ожиданиям от дисплея. Если браузер служит переносимой сессией на основе профиля, profile сохраняет стабильное поведение дисплея при смене хоста. Обсуждайте этот выбор с людьми, которые используют сессию, а не выбирайте режим только по серверным значениям по умолчанию, и проводите проверки доступности с теми же вьюпортом и настройками окна, что и в рабочей среде.

Самые частые ошибки: оставлять режим неявным при смене хост-машины, менять DPR после того, как контекст уже создал страницы, и использовать advanced как общую настройку качества. Задавайте все три политики дисплея явно, когда от них зависит сценарий, создавайте новый контекст для новой политики дисплея и ограничивайте advanced тем сценарием, которому он нужен.

Политику дисплея проще поддерживать, когда она видна рядом с остальной конфигурацией запуска. Указывайте выбранный режим в заметках о развёртывании, тестовых фикстурах и инструкциях по эксплуатации, чтобы коллега мог понять, следует ли сессия профилю или хосту, не открывая страницу. Когда конфигурация переходит из разработки в рабочую среду, сохраняйте режим и связанные настройки окна и экрана и фиксируйте прежний и новый режим вместе с обновлёнными визуальными эталонами каждый раз, когда развёртывание его меняет.

BotBrowser предоставляет параметр --bot-dpr для выбора политики device pixel ratio (profile по умолчанию, real для дисплея хоста и экспериментальный advanced). Если задать его до того, как контекст создаст первую страницу, десктопные и поконтекстные сессии сохраняют один документированный источник масштаба дисплея, и команда может сравнивать прогоны, меняя только этот параметр. BotBrowser не может заставить advanced масштабировать всю страницу заново и не гарантирует идентичных измерений макета или скриншотов, а также не контролирует монитор хоста, адаптивный CSS страницы и то, как сайт использует сообщаемое значение.

О смене соотношения без события resize читайте в руководстве по событиям viewport на мобильных.

Источники

• MDN: Window.devicePixelRatio
• Документация BotBrowser: политика Device Pixel Ratio
• Параметры CLI BotBrowser: --bot-dpr

Практический итог

Считайте --bot-dpr частью входных данных теста: profile для переносимых базовых снимков, real только когда монитор рабочей станции является требованием, а advanced проверяйте на целевом хосте, не принимая его по умолчанию. Храните запись запуска на каждый прогон с версией BotBrowser, профилем, режимом, областью просмотра и целью снимка, чтобы расхождение снимка или адаптивного макета указывало на страницу, а не на незаписанную настройку дисплея.