В коде веб-плеера YouTube обнаружена ошибка вёрстки меню под видео. Из-за неё браузер зацикливается в бесконечной последовательности перерисовок и пересчётов макета: за несколько секунд расход оперативной памяти вкладкой вырастает с сотен мегабайт до нескольких гигабайт, а в тяжёлых случаях превышает 7 ГБ. Симптомы воспроизводятся в Firefox, Brave и Microsoft Edge. Расследование ведётся в трекере Mozilla Bugzilla #2035904; на стороне YouTube исправление не выпущено.
Где сбоит код — гибкое меню под видео
Цикл локализован в HTML-элементе ytd-menu-renderer — контейнере под плеером с кнопками «Нравится», «Не нравится» и «Поделиться». Меню реализовано как гибкое: при нехватке ширины крайняя кнопка скрывается, при появлении свободного места ранее скрытые элементы возвращаются на место. Логику разобрали инженеры Mozilla на основе минифицированного скрипта kevlar_main_module из веб-плеера YouTube.
На каждом кадре в обратном вызове requestAnimationFrame код сравнивает текущую ширину контейнера hostElement.clientWidth с сохранённым значением lastWidth. По результату сравнения вызывается одна из двух веток: shrinkFlexibleMenu обрезает один элемент через slice(0,-1), resetFlexibleItems возвращает все скрытые ранее кнопки.
requestAnimationFrame — браузерный API для синхронизации работы скрипта с частотой обновления экрана. Обратный вызов выполняется перед очередной перерисовкой, обычно 60 раз в секунду.
Почему цикл не завершается
По профилю производительности из отчёта Bugzilla #2035904, ширина hostElement.clientWidth увеличивается после удаления кнопки. По логике скрипта это считается появлением свободного места — и через resetFlexibleItems все кнопки возвращаются обратно. Меню снова переполняется, ширина контейнера снова растёт, и цикл уходит на следующий круг.
Условие выхода «меню умещается без сжатия» в этой ситуации недостижимо: само изменение количества кнопок меняет ширину родительского flex-контейнера, в котором живёт хост меню. Markus Stange из Mozilla в комментарии к багу указал на дополнительное усугубление: каждый обратный вызов requestAnimationFrame внутри цикла планирует ещё два таких же вызова, поэтому количество запланированных перерисовок удваивается на каждом тике. Через несколько кадров планировщик кадров оказывается перегружен, и страница начинает заметно тормозить.
Emilio Cobos Alvarez в том же обсуждении предположил связь с дробным масштабированием экрана, распространённым на Windows. Гипотеза объясняет, почему баг воспроизводится не у всех: на стандартных коэффициентах масштабирования ширина контейнера после удаления кнопки может не вырасти, и цикл стабилизируется на первой же итерации.
Firefox, Brave и Edge: одинаковые симптомы
Жалобы поступают от пользователей Firefox, Brave и Microsoft Edge — то есть и от Gecko-, и от Chromium-движков. Это указывает на источник в коде YouTube, а не в конкретном браузере: часть аудитории Firefox грешила на свежее обновление, но на Brave и Edge картина та же.
Типовая последовательность: после открытия видео расход оперативной памяти вкладкой вырастает с нескольких сотен мегабайт до нескольких гигабайт. Издание PiunikaWeb зафиксировало случаи свыше 7 ГБ на одну вкладку; Tom's Hardware приводит ту же оценку. Загрузка ядер процессора у пострадавших близка к максимальной, а вкладка с видео в части случаев перестаёт реагировать целиком.
В User Story бага перечислены пострадавшие операционные системы: Windows, macOS, Linux и Android. Канал распространения — release, то есть стабильные сборки браузеров, не nightly или beta.
Статус расследования и обходные пути
Запись в Bugzilla открыта 2026 года, на сохраняет приоритет P3, severity S4 и статус NEW. Категория — Web Compatibility :: Site Reports, то есть проблема классифицирована как ошибка стороннего сайта, а не самого Firefox. Диагностика продолжается, патч на стороне браузера не выпускался.
Со стороны Google и YouTube публичных комментариев не было. Гарантированного способа отключить зацикливание из настроек браузера или через скрытые флаги на сегодня нет: в обсуждении в Bugzilla перечислены только шаги воспроизведения и анализ профилей, рекомендации для конечных пользователей в треде не публиковались.
Заключение
Причина рывков и роста расхода памяти на YouTube — не браузер пользователя и не свежий патч Firefox, а ошибка во flex-логике гибкого меню под плеером. До тех пор, пока в YouTube не выпустят правку для скрипта kevlar_main_module, единственный надёжный способ освободить память — закрыть вкладку с видео. Открытый отчёт Bugzilla #2035904 позволяет следить за ходом расследования.