На github опубликован код, приводящий к force restart iOS (11/12 GM) устройств при посещении html-страницы. Также приводит к зависанию Mac OS High Sierra/Mojave при использовании Safari.
Код, приводящий к force restart представляет из себя html-код с большим количеством вложенных div'ов и "сумашедшей" функцией размытия заднего плана:
...
div {
backdrop-filter: blur(10px);
-webkit-backdrop-filter: blur(10px);
width:10000px; height:10000px;
}
</style>
</head>
<body>
<div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>
...Также опубликована PoC html-страница, реализующая данный баг (пользователи Safari переходят на свой страх и риск).
Есть предположение, что баг закрался на уровне ниже, нежели webkit и может привести к более серьезным последствиям. Также, использование данного бага может быть применимо в социотехнических компаниях и дурацких розыгрышах, так что советую крайне подозрительно относится ко всем ссылкам, тем более что на iOS все браузеры, по сути, это надстройка над Сафари.
Комментарии (54)
aram_pakhchanian
16.09.2018 01:21Проблема не в Webkit, а в самом Safari, иначе другие браузеры на Webkit вели бы себя так же. Может быть все что угодно, например, бесконечная рекурсия, которая быстро забивает память.
fhabr
16.09.2018 01:39Да, на это и похоже. Целиком система не вешается, по ssh картина такая:
Апд: Хотя и в нормальном режиме там 80G виртуальной памяти выделено, так что хз…
Ещё в 10.14 так и не починили Preview для просмотра jpeg, а в iOS 12 как был глюк в Books со сбрасыванием размера страницы (pdf) при её случайном покачивании из стороны в сторону, так и остался.fhabr
16.09.2018 01:48Всё-таки действительно память забивается. Похоже, кто-то забыл про полноту условий выхода из рекурсии )
staticlab
16.09.2018 02:12иначе другие браузеры на Webkit вели бы себя так же
Насколько кодовая база Blink (Chrome, Opera) сейчас синхронизируется с Webkit (Safari)?
Kobalt_x
16.09.2018 11:49Всё браузеры под iOS работают на WebKit, от Apple даже chrome
iShatokhin
16.09.2018 12:50Epiphany. Проверил на Linux — проблеме не подвержен (точнее, версия из репов пока backdrop-filter не поддерживает).
homm
16.09.2018 02:26+1Там вполне конечная рекурсия, просто очень затратная. backdrop-filter — это очень дорогая операция.
Sabubu
16.09.2018 04:24Это не может быть связано с видеоускорителем? Создаются большие текстуры и его ресурсы заканчиваются, после чего отображаться уже не может ничего, включая системные окна?
t0_ot
16.09.2018 18:29Просто только Safari поддерживает размытие заднего фона. Видимо код для размытия родителя косячный.
homm
16.09.2018 01:55А почему в хроме эта страница имеет бесконечную высоту не сообщается?
Mad__Max
16.09.2018 02:08-1Она не бесконечная, а просто очень большая. Несколько миллионов пикселей по высоте.
При ручном листании правда устанешь ждать, но бегунком на скроллбаре вполне пролистывается до конца.
При этом проблем со стабильностью или производительностью в Хроме или Лисе подобная страница не вызывает — памяти съедает не больше 100 Мб, что по меркам современных ожиревших браузеров норма, процессор особо не грузит. Тот же статья на харбре или ЖЖ с несколькими сотнями комментариев и памяти и ресурсов процессора больше жрут.
Хром при этом показывает все в точности как и было задумано «дизайнером»: там же в сходном в коде несколько тысяч блоков в которых через стили прописаны размеры 10000 х 10000 пикселей. Так что при отображении «в лоб» и должна получаться страничка в миллионы пикселей высотой.
А вот Лиса «халтурит» — видимо потому что эти блоки пустые (без контента) и рендерит только 1й.homm
16.09.2018 02:23Там в исходном в коде несколько тысяч вложенных друг в друга блоков в которых через стили прописаны размеры 10000 х 10000 пикселей. То есть все вместе они должны занимать 10000 х 10000 пикселей, что корректно отображает ФФ и Сафари, если убрать backdrop-filter.
При этом проблем со стабильностью или производительностью в Хроме или Лисе подобная страница не вызывает
Еще бы вызывала, в них же нет никаких backdrop-filter.
Deathik
16.09.2018 11:17А никто не прибывал в Edge? MDN и CanIUse говорят, что поддерживает backdrop-filter.
namikiri
16.09.2018 13:13+1Edge несколько раз пытается отрендерить страничку, в конце концов понимает, что там какая-то дичь, и выдаёт сообщение об ошибке загрузки.
Скриншот
srhbdv
16.09.2018 16:51Зато есть просто filter.
Вставка его в вместо backdrop, у меня почему-то, приводит к зависанию всей системы, если открыть его в Firefox, решающейся только перезагрузкой. Windows10. Другие браузеры, либо не открывают, либо бесконечно думают, но не падают.
ExplosiveZ
16.09.2018 17:38Firefox 62, значок загрузки по-середине экрана на вкладке с хаком, система не зависает.
1 ядро загружено на 100%, потребление памяти, кажется, не растёт.
vsb
16.09.2018 22:48Под Chrome на Windows 10 не виснет, только грузит процессор. Правда весь экран моргнул чёрным цветом через некоторое время, похоже, что таки в видеодрайвере что-то пошло не так.
Mad__Max
17.09.2018 02:13Забавно. Старые FF (47 или 52.х ESR) вообще без проблем открывают страницу.
Несколько секунд подтормаживания, потом сильно размытые блюром рожицы как пложено показываются. Загрузка процессора при открытии и при скроллинге высокая, но если скролл не дергать то, то не грузит.
Потребление памяти тоже в норме.
А вот новых ФФ (квантум) при попытке открытия сразу выжирают всю доступную память (в моем случае около 10 ГБ) и на 100% грузит одно из ядер процессора. Но все-равно ничего не падает — ОС предупреждает о нехватке памяти, но все продолжает работать нормально, включая сам браузер — другие открытые в нем вкладки работают нормально и даже не тормозят.
Update:
Если поняблюдать за потреблением памяти в новом ФФ, то оно после скачка до максимума (предела доступной в системе памяти) начинает постепенно снижаться.
Решил посмотреть чем закончится? В результате минут через 5 он все-таки смог открыть и нормально показать такую страничку. При этом уже не тормозя и не пожирая память.sumanai
17.09.2018 19:52в моем случае около 10 ГБ
Ну так в телефонах столько нету, поэтому и глючит.Mad__Max
18.09.2018 02:37А он не конкретно 10 Гб хочет, а «сколько есть». Будет 20 ГБ доступно, сожрет 20.
Дальше уже от корректности обработки таких неадеватных запросов приложения (в данном случае браузера) со стороны ОС(в данном примере iOS) зависит.
Адекватно — отдать приложению сколько есть свободной, не нарушая работу других программ и ядра, кроме общего замедления работы (из-за начавшегося активного свопа на диск к примеру и снижения размера дискового кэша до минимума).
Неадекватно — упасть в «синьку» или уйти в ребут от таких «жадных» запросов прикладного софта.
Mad__Max
17.09.2018 01:58Дейсвительно, не обратил внимания, что дивы вложенные. Значит FF правильно рендерит, это наоборот в Хроме глюк.
Ну тогда не понятно в чем проблема. Блюр фильтр конечно довольно ресурсоемкая вещь, но не то, чтобы критически. Попробовал в фотошопе открыть картинку на 100 Мегаписклей (10000 х 10000) и применить к ней всей гаус-блюр с радиусом размытия 10px как в примере.
Никаких проблем — секунд на 5-7 работы на уже 10 летней давности процессоре и около 700 МБ использованной памяти.
В FF ниже рабочий пример выложили, он тоже без проблем открывается. При скролинге такой странички правда жутко тормозит, но не только ОС, но и сам браузер (остальные вкладки) продолжают работать без проблем, никаких зависаний или вылетов. После закрытия вкладки подторможивания браузера сразу прекращаются.
Потребление памяти тоже умеренное — где-то +300-400 Мб при открытии.
Возможно в сафари такой же глюк как и хроме и он вложенные дивы пытается последовательно вывести и умирает при попытке наложения фильтра на картинку размером в несколько десятков гигапикселей (10000 х несколько миллионов) вместо 100 MPx как должно быть при корректном отображении?
У кого сафари под iOS под рукой — можете проверить убрав фильтр, но оставив ту же страничку с диком количеством вложенных див-ов — как будет открисоывать?Mad__Max
17.09.2018 03:07В новых ФФ оказалось все запущеннее.
1. После открытия подобной страницы Лиса «заражается» — при последующих запусках, один из ее процессов начинает сразу со старта жрать по 5 ГБ памяти и грузить на максимум одно ядро. И дело вовсе не в автоматически открывающейся вкладке с стараницей (из сохраненной сессии к примеру) — открытых видимых вкладок НЕТ, новые владки открывают без проблем. Но через дисперчер задач видно, что где-то во внутренностях он продолжает фигней страдать в одном из скрытых процессов (чем занимается этот процесс вообще фиг знает — браузер на его прибитие вообще никак не реагирует). И даже очистка кэша/истории не помогает, лечится только полной очисткой браузера (сносом профиля — Информация для решения проблем ==> очистка FireFox)
2. Оказалось, что у меня и на той машине не самая свежая версия стояла. Обновился до последней (62й) — там уже не только мгновенно сжирает всю память, но и системе плоховато становится. До зависаний и перезагрузок правда не доходит, но процесс system (ntoskrln.exe) грузит процессор на максимум и тормозит и подглючивает уже вообще вся система, а не только браузер.
В какой раз убеждаюсь, что чем дальше тем хреновее делают современный браузеры. Что-то улучшили, свистелок-перделок добавили, зато вместо с ними добавили пачку глюков, в очередной раз прибавили жор ресурсов, опционально поломали совместимости.
На этом аномальном примере особо выпукло заметно:
FF 47-52: Открывается без проблем, подтормаживает секунд 5 при открытии, потребление памяти нормальное, на систему и даже другие вкладки никак не влияет
FF 57: При открытии жестко тормозит несколько минут, постепенно сжирает всю доступную память, но работу остальной системы не нарушает, кроме как перетягивания на себя ресурсы (в основном памяти + 1 ядро под постоянной загрузкой)
FF 62: Мгновенно сжирает всю доступную память + практически вешает систему нарушая работу всех программ — несколько работавших сразу вылетили с ошибками.
homm
17.09.2018 04:59Блюр фильтр конечно довольно ресурсоемкая вещь, но не то, чтобы критически. Никаких проблем — секунд на 5-7 работы на уже 10 летней давности процессоре.
Вы продолжаете «не обращать внимание». Backdrop-filter накладывается не на содержимое элемента, а на фон, который под ним. А фоном для элемента в том числе является родительский элемент. А там 3485 вложенных элементов. Более того, это фильтр гауссова размытия, так что для того, чтобы отрисовать экран 1000x1000 пикселей, нужно взять фон примерно 1030x1030 пикселей под ним. В результате уже где-то на 300-м элементе и дальше нужно размывать все 10000x10000 пикселей, а не только то, что видно на экране.
Возможно в сафари такой же глюк как и хроме и он вложенные дивы пытается последовательно вывести
Я уже выше писал, что нет, Сафари верно показывает вложенные дивы. Более того, если располагать элементы последовательно, нет никакой проблемы это отрисовать — нужно будет отрисовывать только то, что на экране, а на экране строго фиксированное количество пикселей, еще и пустых в случае filter, а не backdrop-filter.
yul
16.09.2018 09:01Я так подозреваю, этот код использовался для нагрузочного тестирования хрома, пока кто-то не решил его попробовать в других браузерах. Во всяком случае, вряд ли это с живого сайта взято )
HappyGroundhog
16.09.2018 09:48Попытка открыть это в Firefox на Ipad 4 (ios 10.3.3) мгновенно отправила планшет в ребут) Вишенка на торте то, что FF после перезагрузки услужливо попытался открыть мне последнюю открытую страницу…
AnarchyMob
16.09.2018 17:59Не могу понять почему в iOS, macOS при возникновении в процессе SOE перезагружается вся система, вместо того чтобы просто убить процесс/поток?
srhbdv
16.09.2018 11:17У меня Edge отказался загружать страницу PoC вовсе. Firefox загрузил и отрендерил лишь первый блок, как выше отписали, схалтурив. Хром загрузил и отрендерил все как надо. IE повел себя как эдж, сообщив, что он сам закрыл вкладку.
tomus
16.09.2018 11:17На днях решал проблему:
На div был повешен обработчик onclick и на устройствах iOs клик не срабатывал. Добавил диву style: «cursor: pointer;», в результате страница стала тупо зависать на устройствах iOs при клике по этому диву. Устройство при этом хорошо разогревалось.
Проблема решилась заменой дива на «а»Max_JK
16.09.2018 11:48это нужно исправлять на уровне системы а не сайтов, надеюсь вы написали баг репорт.
Dartess
16.09.2018 11:42Chrome за флагом поддерживает
backdrop-filter, если включить, то вместо браузера получаем чёрный прямоугольник. На систему, благо, никак не влияет (Windows).srhbdv
16.09.2018 16:57+1Если использовать даже просто filter, получим тот же самый прямоугольник
Marumaru
16.09.2018 22:16При открытии вашей ссылки на смартфоне виснет браузер. Android 8, Via browser
Max_JK
16.09.2018 11:50Мои результаты тестов, десктоп и мобильные сработали одинаково
Хром — нормально
Опера — нормально
Лиса — схалтурила и загрузила не всё, похоже стоит ограничение на глубину рекурсии
Edge — отказался грузить
IE 11 — отказался грузить
dima_bolonikov
16.09.2018 22:16Проверил на маке 2016 прошке — работает, мак завис полностью, даже трекпад перестал ощущаться
FlamyXD
Мне кажется, что подобные баги происходят потому что iOS — закрытая система
khim
Нет, подобные баги происходят потому, что люди несовершенны.
А вот уже то, что их невозможно на iOS «обойти» использованием другого браузера — да, тут из-за закрытости экосистемы…