Firefox 153 для фронтенда: что проверить в Intl.Locale и Error.stackTraceLimit

Firefox 153 на момент подготовки материала находится в beta-канале. В релизных заметках для разработчиков отмечены поддержка методов `Intl.Locale` и свойства `Error.stackTraceLimit`. Это полезные изменения для интернационализации и диагностики, но beta-возможность нельзя включать без feature detection и запасного пути.

`Intl.Locale` помогает получить сведения о календаре, часовых циклах, нумерации и других настройках локали. `Error.stackTraceLimit` позволяет управлять количеством кадров стека ошибки в средах, где свойство поддерживается.

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

Для разработки дополнительная глубина стека помогает найти источник ошибки. В продакшене чрезмерное логирование может увеличить объём данных и раскрыть внутренние пути. Устанавливайте лимит осознанно и не отправляйте пользователю полный стек.

Новые возможности полезны в формах, календарях, фильтрах и системах логирования. Сначала определите сценарий, затем проверьте, есть ли практическая польза.

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

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

Не проверяйте браузер по строке User-Agent. Проверяйте наличие конкретного свойства или метода и готовьте замену.

Для нового метода `Intl.Locale` убедитесь, что объект и функция доступны. Если проверка не прошла, используйте более простой формат или статичное описание. Пример должен быть минимальным и не ломать старый браузер:

Значение `gregory` — fallback для интерфейса, а не утверждение о предпочтениях пользователя.

Если функция недоступна, оставьте основной сценарий: обычное поле даты, понятный формат и ручную настройку. Пользователь не должен видеть техническое сообщение о beta-возможности.

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

Не переносите рабочие cookies в beta-профиль. Для диагностики сохраняйте только обезличенную консоль. Сравните время работы и поведение формы с основной версией браузера.

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

Beta не гарантирует одинаковое поведение во всех каналах. Даже после стабильного релиза функция может быть ограничена платформой или настройками.

Пишите в документации дату и версию проверки. Если функция не критична, используйте её как улучшение, а не основу интерфейса.

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