В начале 2018 года в нашем блоге появился цикл статей, посвящённый шестой проверке исходного кода проекта Chromium. Цикл включает в себя 8 статей, посвященных ошибкам и рекомендациям по их предотвращению. Две статьи вызвали бурное обсуждение, и до сих пор на почту мне изредка приходят комментарии касательно тем, затронутых в них. Пожалуй, следует дать некоторые дополнительные пояснения и, как говорится, расставить точки над i.
Читать полностью »
В сентябре прошлого года разработчики Chrome выдвинули радикальное предложение: изменить отображение URL в браузере. В некоторых изданиях сразу появились статьи с паническими заголовками «Google хочет убить URL»
Теоретически, Google выгодно, чтобы пользователи заходили на все сайты через поиск, а не напрямую по URL из браузера. Наверное, для этой цели в своё время адресную строку совместили с поисковой строкой. Но до полного исчезновения адресной строки ещё далеко. Пока что Google делает лишь первые шаги, по чуть-чуть отдавая браузеру Chrome контроль над отображением URL. Это делается для безопасности пользователей.
Google говорит, что синтаксис URL слишком труден для массовой аудитории.
Читать полностью »
Разработчик uBlock Origin заявил, что его расширение для блокировки рекламы не сможет работать, если будут приняты изменения в Chromium. Речь идёт о внедрении declarativeNetRequest API, которые лишают возможности использовать webRequest API. Google считает, что изменения необходимы для быстрой работы встроенного в Chromium блокировщика рекламы, а также реализации в браузере функциональности, которая сейчас есть в Adblock Plus (тот же синтаксис и т. д.).
Проблема в том, что эти интерфейсы плохо совместимы с текущей схемой работы uBlock Origin: «Если блокировщики смогут работать только через эти (весьма ограниченные) declarativeNetRequest API, то фактически это означает, что два блокировщика, которые я поддерживал в течение многих лет, uBlock Origin и uMatrix, больше не смогут существовать», — написал Реймонд Хилл.
Читать полностью »
Современный браузер — это крайне сложный проект, в котором даже безобидные с виду изменения могут приводить к неожиданным сюрпризам. Поэтому существует множество внутренних тестов, которые должны такие изменения отловить до релиза. Тестов никогда слишком много не бывает, поэтому полезно использовать в том числе сторонние публичные бенчмарки.
Меня зовут Андрей Логвинов, я работаю в группе разработки рендеринг-движка Яндекс.Браузера в Нижнем Новгороде. Сегодня я расскажу читателям Хабра о том, как устроено управление памятью в проекте Chromium на примере одной загадочной проблемы, которая приводила к падению производительности в тесте Speedometer. Этот пост основан на моём докладе с мероприятия Яндекс.Изнутри.
Несколько дней назад появились слухи, что Microsoft разрабатывает браузер на базе Chromium, который будет поставляться по умолчанию вместо Edge. Основанием стало то, что сотрудники Microsoft вдруг стали делать коммиты в свободный проект. Сейчас Microsoft официально заявила, что действительно отказывается от собственного движка EdgeHTML в пользу Chromium в десктопной версии браузера.
Для веб-разработчиков это большое облегчение: при тестировании одним движком станет меньше, а куча оригинальных особенностей IE/Edge канут в историю. Однако по мнению Mozilla, такое решение коллег из Microsoft создаёт угрозу для интернета, потому что доминирование единой платформы от Google становится ещё более тотальным. Есть угроза, что Firefox уйдёт в настолько маргинальную нишу, что разработчики даже перестанут тестировать сайты под него. Доля Firefox продолжает снижаться, В декабре 2018 года упала до минимальных значений за много лет: менее 9% на десктопах.
Читать полностью »
Конец многолетнему противостоянию, хотя скорее это было избиение
Начиная с 2015 года компания Microsoft активно продвигала свой новый браузер, который сначала носил кодовое имя Spartan, а после получил название Edge. Тогда компания признала, что Internet Explorer морально устарел и многие пользователи ожидали какого-то прорыва от главного поставщика пользовательских ОС в мире, однако вместо инноваций сообщество получило того же «ослика», но в новой упаковке.
Спустя почти четыре года Microsoft практически расписалась в поражении на рынке браузеров и признала слабость используемого ими EdgeHTML. И несколько месяцев назад инженеры компании приступили к разработке собственного браузера на базе Chromium — наиболее популярного современного движка — о чем свидетельствуют коммиты в Chromium Gerrit. Новый проект получил кодовое имя Anaheim.
Читать полностью »
Как мы перевели работу с HTML в 1С:Предприятии с Internet Explorer на WebKit
Возможность отображать HTML в формах 1С появилась в платформе 1С:Предприятие еще в версии 8.0 (выпущена в 2003 г.). Для работы с HTML в платформе использовался движок браузера Internet Explorer (1С:Предприятие на тот момент работало только под Windows). Движок браузера использовался платформой для утилитарных целей. Например, писать с нуля полноценный элемент для редактирования текста а-ля Word – с возможностью различных цветовых и шрифтовых решений, вставки картинок и т.д. – весьма непростая задача. А если задействовать для этих целей HTML и использовать в качестве средства отображения движок интернет-браузера, то задача сильно упрощается. Также при помощи движка был реализован ряд других механизмов (например, отображение справочной информации) и элементов (например, Планировщик).
Ну а возможность для разработчиков прикладных решений отображать с помощью HTML нестандартный, по меркам мира учетных систем, дизайн позволяла иногда привносить разнообразные приятные изюминки в интерфейс бизнес-приложений.
Время шло, платформа стала поддерживать сначала Linux, а потом и macOS. Для работы с HTML в этих ОС Internet Explorer не подходил по понятным причинам; в Linux нами был задействован WebKitGTK+, а в macOs — библиотека на основе Cocoa. Таким образом, единство кодовой базы для разных ОС (которое мы стараемся поддерживать для клиентского кода на уровне 95%) в этой области было нарушено. Ну и движок IE к этому времени стал источником ряда проблем.
Читать полностью »
Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json
О чём вообще идёт речь? Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Ага, вот так берём и отрисовываем, конечно.
Читать полностью »
Когда браузерам не хватает памяти, они выгружают из нее наиболее старые вкладки. Это раздражает, потому что клик по такой вкладке приводит к принудительной перезагрузке страницы. Сегодня мы расскажем читателям Хабра о том, как команда Яндекс.Браузера решает эту проблему с помощью технологии Hibernate.
Браузеры, основанные на Chromium, создают по процессу на каждую вкладку. У этого подхода множество достоинств. Это и безопасность (изоляция сайтов друг от друга), и стабильность (падение одного процесса не тянет за собой весь браузер), и ускорение работы на современных процессорах с большим количеством ядер. Но есть и минус – более высокое потребление оперативной памяти, чем при использовании одного процесса на всё. Если бы браузеры ничего с этим не делали, то их пользователи постоянно видели бы что-то подобное:
В проекте Chromium борются с потреблением памяти фоновыми вкладками с помощью очистки различных кэшей. Речь не про тот кэш, в котором хранятся картинки загруженных страниц. С ним проблем нет – он живет на жестком диске. В современном браузере много другой закэшированной информации, которая хранится в оперативной памяти.
Также в Chromium уже достаточно давно работают над тем, чтобы останавливать JS-таймеры в фоновых вкладках. Иначе очистка кэшей теряет смысл, т.к. активности в фоновых вкладках их восстанавливают. Считается, что если сайты хотят работать в фоне, то нужно использовать service worker, а не таймеры.
Привет Хабр, ранее, в своем блоге по безопасности, мы объявили о планах по снижению доверия Chrome к сертификатам Symantec (включая принадлежащие Symantec бренды, такие как Thawte, VeriSign, Equifax, GeoTrust и RapidSSL). В этом посте описывается, как владельцы сайтов могут определить, повлияет ли на них снижение доверия к сертификатам Symantec, и если да, то что нужно сделать и когда. Отказ от замены этих сертификатов приведет к поломке сайта в будущих версиях основных браузеров, включая Chrome и Firefox.
