Как создать свой браузер
Как создать свой собственный браузер для Windows 10 на HTML и JavaScript
За последние несколько месяцев мы внесли множество улучшений в движок рендеринга Microsoft Edge (EdgeHTML), делая особый акцент на совместимости с современными браузерами и соответствии новым и грядущим стандартам. Помимо того, что EdgeHTML лежит в основе браузера Microsoft Edge, он также доступен для приложений на Universal Windows Platform (UWP) через элемент управления WebView. Сегодня мы хотим рассказать, как можно использовать WebView для создания своего браузера в Windows 10.
Используя стандартные веб-технологии, включая JavaScript, HTML и CSS, мы создали простое UWP-приложение, которое содержит внутри WebView и реализует базовую функциональность: навигацию и работу с избранным. Подобные приемы могут быть использованы в любом UWP-приложении для прозрачной интеграции веб-контента.
В основе нашего примера лежит мощный элемент управления WebView. Помимо комплексного набора API, данный элемент также позволяет преодолеть некоторые ограничения, присущие iframe, например, отслеживание фреймов (когда некоторый сайт меняет свое поведение в случае выполнения внутри iframe) и сложность определения загрузки документа. В дополнение x-ms-webview, — так WebView задается в HTML, — дает доступ к функциональности, не доступной в iframe, в частности, улучшенный доступ к локальному контенту и возможности делать снимки содержимого. Когда вы используете элемент управления WebView, вы получаете тот же самый движок, что и в Microsoft Edge.
Создаем браузер
Как было написано выше, браузер базируется на элементе управления WebView для HTML, а для создания и оживления пользовательского интерфейса в основном используется JavaScript. Проект создан в Visual Studio 2015 и представляет собой универсальное Windows-приложение на JavaScript.
Помимо JavaScript, мы также использовали немного HTML и CSS, а также некоторое количество строк кода на C++ для поддержки комбинаций клавиш, но это не требуется в простом случае.
Также мы пользуемся новыми возможностями нового ECMAScript 2015 (ES2015), поддерживаемыми в Chakra, JavaScript-движке, работающем в Microsoft Edge и элементе управления WebView. ES2015 позволил нам сократить количество генерируемого и шаблонного кода, тем самым существенно упростив реализацию идеи. Мы использовали следующие возможности ES2015 при создании приложения: Array.from(), Array.prototype.find(), arrow functions, method properties, const, for-of, let, Map, Object.assign(), Promises, property shorthands, Proxies, spread operator, String.prototype.includes(), String.prototype.startsWith(), Symbols, template strings и Unicode code point escapes.
Интерфейс пользователя
Пользовательский интерфейс включает следующие десять компонентов:
Дополнительная функциональность
Мы также реализовали несколько дополнительных возможностей, чтобы сделать работу с браузером еще более приятной:
Использование WebView
Введенный для JavaScript-приложений в Windows 8.1 элемент управления WebView, иногда также упоминаемый по имени тега x-ms-webview, позволяет хостить веб-контент внутри вашего Windows-приложения. Он доступен как для HTML, так и для XAML.Для начала работы достаточно разместить соответствующий элемент в коде страницы.
Разработка браузера
Мы будем использовать 15 различных API x-ms-webview. Все кроме двух из них управляют навигацией между страницами с некотором смысле. Давайте посмотрим, как можно использовать данные интерфейсы для создания различных элементов UI.
Управление кнопками назад и вперед
Когда вы нажимаете кнопку назад, браузер возвращает предыдущую страницу из истории браузера, если она доступна. Аналогично, когда вы нажимаете кнопку вперед, браузер возвращает последующую страницу из истории, если она также доступна. Для реализации подобной логики мы используем методы goBack() и goForward(), соответственно. Данные функции автоматически осуществят навигацию на корректную страницу из стека навигации.
После перехода на некоторую страницу, мы также обновляем текущее состояние кнопок, чтобы предотвратить «возможность» навигации, когда мы достигаем одного из концов стека навигации. Другими словами, мы отключаем кнопки навигации вперед или назад, проверяя свойства canGoBack или canGoForward на равенство false.
Управление кнопками обновления и остановки
Кнопки обновления и остановки слегка отличаются от остальных компонент панели навигации тем, что они используют одно и то же место в UI. Когда страница загружается, нажатие на кнопку остановит загрузку, спрячет «кольцо прогресса» и отобразит иконку обновления. И наоборот, когда страница загружена, нажатие на кнопку запустит обновление страницы и (в другой части кода) отобразит иконку остановки. Мы используем методы refresh() или stop() в зависимости от текущих условий.
Управление адресной строкой
В целом, реализация адресной строки может быть очень простой. Когда адрес URL введен в текстовое поле, нажатие Enter вызовет метод navigate(), используя содержимое input-элемента адресной строки в качестве параметра.
Однако современные браузеры пошли сильно дальше и внедряют дополнительную функциональность для удобства пользователей. Это добавляет некоторую сложность в реализации – и тут все зависит от сценариев, которые вы хотите поддержать.
Вот пример сценария, который мы попробовали реализовать. Допустим, в адресную строку введено значение “microsoft.com”. Адрес не является полным. Если такое значение передать в метод navigate(), он завершится неудачей. Наш браузер должен знать, что URL не полный, и уметь определить, какой корректный протокол подставить: http или https. Более того, возможно, что введенное значение и не предполагалось адресом. К примеру, мы могли ввести в адресную строку значение “seahawks”, надеясь, что, как и во многих браузерах, строка также работает как поле поиска. Браузер должен понять, что значение не является адресом, и попробовать «найти» его в поисковой системе.
Отображение favicon
Запрос favicon – нетривиальная задача, так как существует несколько способов, как икона может быть задана. Самый простой способ – это проверить корень веб-сайта на наличие файла «favicon.ico». Однако некоторые сайты могут быть на поддомене и поэтому иметь отличную иконку. К примеру, иконка на “microsoft.com” отличается от иконки на “windows.microsoft.com”. Чтобы исключить двусмысленность, можно использовать другой способ — проверить разметку страницы на наличие link-тека внутри документа с rel-атрибутом, равным “icon” или “shortcut icon”.
Мы используем метод invokeScriptAsync(), чтобы вставить внутрь элемента управления WebView скрипт, который вернет строку в случае успеха. Наш скрипт ищет внутри страницы все элементы с link-теком, проверяет, если rel-атрибут содержит слово “icon”, и в случае совпадения возвращает значение “href”-атрибута назад в приложение.
Как упомянуто выше, мы используем в нашем коде возможности из новой спецификации ES2015. Вы могли заметить использование стрелочной нотации во многих примерах выше, а также ряд других возможностей. Вставляемый скрипт – это отличный пример улучшения кода, достигаемого за счет поддержки ES2015.
Поддержка комбинаций клавиш
В отличие от возможностей, которые мы реализовали выше, поддержка комбинаций клавиш потребует от нас небольшого куска кода на C++ или C#, обернутого в виде Windows Runtime (WinRT) компонента.
Чтобы определить нажатие горячих клавиш для выполнения тех или иных действий, например, чтобы при нажатии комбинации Ctrl+L выделять адресную строку или по F11 переключаться в полноэкранный режим, нам нужно вставить еще один скрипт в WebView. Для этого мы используем метод invokeScriptAsync(), который мы уже упоминали выше. Однако, нам нужно как-то сообщать назад в слой приложения, когда те или иные клавиши нажаты.
С помощью метода addWebAllowedObject(), мы можем выставить для инжектируемого кода метод, через который можно будет передавать нажимаемые клавиши в слой приложения на JavaScript. Также важно понимать, что в Windows 10, элемент управления WebView выполняется в отдельном потоке. Нам нужно создать диспетчер, который будет передавать события в поток UI, чтобы слой приложения мог их обрабатывать.
Внешний вид браузера
Теперь, когда мы разобрались с ключевыми API WebView, давайте немного улучшим внешний вид нашего браузера.
Брендирование заголовка
Используя API Windows Runtime, мы можем поменять свойство ApplicationView.TitleBar, чтобы настроить цветовую палитру все компонентов заголовка приложения. В нашем браузере при загрузке приложения мы меняем цвета так, чтобы они соответствовали панели навигации. Мы также обновляем цвета при открытии меню, чтобы соответствовать фону меню. Каждый цвет нужно задавать как объект с RGBA свойствами. Для удобства мы создали вспомогательную функцию, генерирующую нужный формат из шестнадцатеричной строковой записи.
Прочие возможности
Индикация прогресса, а также меню настроек и избранного используют CSS transitions для анимации. Из меню настроек временные веб-данные можно очистить, используя метод clearTemporaryWebDataAsync(). А в меню избранного отображаемый список хранится в JSON-файле в корневой папке перемещаемого хранилища данных приложения.
Исходный код
Полный пример кода доступен в нашем репозитарии на GitHub. Вы можете также попробовать демонстрационный браузер, установив соответствующее приложение из Windows Store, или развернув приложение из проекта для Visual Studio.
Разрабатываем свой браузер с нуля. Часть первая: HTML
Продолжаем цикл статей по разработке браузерного движка.
В данной статье я расскажу как создать самый быстрый HTML-парсер c DOM. Мы рассмотрим HTML спецификацию и чем она плоха относительно производительности и потребления ресурсов при разборе HTML.
С данной темой я докладывался на прошедшем HighLoad++. Конференцию не каждый может посетить, плюс в статье больше деталей.
Я предполагаю, что читатель обладает базовыми знаниями об HTML: теги, ноды, элементы, пространство имён.
Спецификация HTML
Прежде чем начать хоть как-то затрагивать реализацию HTML-парсера необходимо понять какой HTML спецификации верить.
Существует две HTML спецификации:
UPDATE: К сожалению, приведенные ссылки на спецификации не открываются из России. Видимо, «эхо войны» с телеграмм.
Процесс парсинга HTML
Процесс построения HTML дерева можно разделить на четыре части:
Рассмотрим каждую стадию по отдельности.
Декодер
Токенизатор принимает на вход юникод символы (code points). Соответственно, нам необходимо конвертировать текущий байтовый поток в юникод символы. Для этого необходимо воспользоваться спецификацией Encoding.
Если мы имеем HTML с неизвестной кодировкой (нет HTTP заголовка) то нам необходимо её определить до начала декодирования. Для этого мы воспользуемся алгоритмом encoding sniffing algorithm.
В спецификации Encoding оговаривается минимальный набор поддерживаемых кодировок браузерным движком (всего 21): UTF-8, ISO-8859-2, ISO-8859-7, ISO-8859-8, windows-874, windows-1250, windows-1251, windows-1252, windows-1254, windows-1255, windows-1256, windows-1257, windows-1258, gb18030, Big5, ISO-2022-JP, Shift_JIS, EUC-KR, UTF-16BE, UTF-16LE и x-user-defined.
Предварительная обработка
После того как мы декодировали байты в юникод символы нам необходимо провести «зачистку». А именно, заменить все символы возврата каретки ( \r ) за которыми следует символ перевода строки ( \n ) на символ возврата каретки ( \r ). Затем, заменить все символы возврата каретки на символ перевода строки ( \n ).
Но, на самом деле так никто не делает. Делают проще:
Если попался символ возврата каретки ( \r ) то смотрим есть ли символ перевода строки ( \n ). Если есть то меняем оба символа на символ перевода строки ( \n ), если нет то меняем только первый символ ( \r ) на перевод строки ( \n ).
На этом предварительная обработка данных завершена. Да, всего-то надо избавиться от символов возврата каретки, чтобы они не попадали в токенизатор. Токенизатор не ожидает и не знает, что делать с символом возврата каретки.
Ошибки парсинга
Чтобы в дальнейшем не возникало вопросов стоит сразу рассказать, что такое ошибка парсинга ( parse error ).
На самом деле ничего страшного. Звучит грозно, но по факту это лишь предупреждение о том, что мы ожидали одно, а имеем другое.
Ошибка парсинга не остановит процесс обработки данных или построение дерева. Это сообщение которое сигнализирует, что у нас не валидный HTML.
К слову, некоторые ошибки парсинга ведут к последствиям. К примеру, если указать «плохой» то HTML дерево будет помечен как QUIRKS и изменится логика работы некоторых DOM функций.
Токенизатор
Как уже было сказано ранее, токенизатор принимает на вход юникод символы. Это конечный автомат (state machine) который имеет 80 состояний. В каждом состоянии условия для юникод символов. В зависимости от пришедшего символа токенизатор может:
Токенизатор создает токены шести видов: DOCTYPE, Start Tag, End Tag, Comment, Character, End-Of-File. Которые поступают в стадию построения дерева.
Примечательно, что токенизатор знает не о всех своих состояниях, а где о 40% (взял с потолка, для примера). «Зачем же остальные?» — спросите вы. Об остальных 60% знает стадия построения дерева.
Это сделано для того, чтобы правильно парсить такие теги как
В данной статье я хочу поделиться мыслями на счёт создания собственного браузерного движка. Мы рассмотрим текущие браузеры и браузерные движки. Вспомним про Modest и узнаем его нелёгкую судьбу.
Это будет цикл статей в которых мы создадим свой собственный минималистичный браузерный движок. Каждая статья будет подкреплена реальным кодом и примерами.
По прошествии десяти статей у нас с вами будет минимальная рабочая версия браузерного движка, сильно минимальная. После этого, если запал не уйдёт и будет интерес сообщества, продолжим, и в итоге доберёмся до JS.
И конечно, первым делом необходимо понять, что такое браузер и браузерный движок.
Браузер и браузерный движок
Существующий мир сложно представить без браузеров. Они есть на многих устройствах: компьютеры, лэптопы, телефоны, игровые приставки. Если представить браузер в виде машины то браузерный движок это всё то, что скрыто под капотом вашего автомобиля.
Браузеры как и автомобили могут отличаться внешним видом и содержимым под капотом. Цвет, кнопочки на панели, аудиосистема. У кого-то под капотом двигатель V8, а у кого-то там масло течёт.
Браузер объединяет периферию и предоставляет функционал позволяющий манипулировать движком, его поведением, предоставляет дополнительные сервисы.
Браузерный движок выполняет всю «грязную» работу: загрузка, обработка, отрисовка данных и все возможные расчёты.
Всё как в автомобилях. Есть салон в котором присутствует педаль газа, тормоза и множество переключателей полезных и понятных пользователю. А есть большая механическая часть скрытая от пользователя под капотом.
Кто создает браузеры и движки
Разработкой собственного браузера занимается множество компаний: Google, Mozilla, Apple, Microsoft, Opera Software, Яндекс, Ростелеком, Vivaldi Technologies, много их…
Каждый добавляет какие-то свои «фишки», сервисы в создаваемый браузер. К примеру, Яндекс интегрирует свои сервисы, поиск.
С браузерными движками дела обстоят кардинально иначе. Вот список движков, их разработчиков и обладателей:
Это основные обладатели и разработчики движков. В разработке им помогают сторонние компании на определенных условиях.
Например, рассмотрим самый популярный проект от компании Google — Chromium. Данный проект содержит в себе движок Blink. Создавать данный проект Google помогают такие компании как Intel, Facebook, IBM, LG Electronics, NVIDIA, Yandex. Полный список можно посмотреть тут.
Условия на которых компании помогают создавать Blink/Chromium описаны в разделе Legal stuff на сайте проекта Chromium. Если кратко, то всё что вы создаёте принадлежит (не эксклюзивно) Google.
Браузеры компаний Opera, Яндекс, Ростелеком и другие используют именно этот браузерный движок. Если быть до конца откровенным то заявления вроде «у нас есть свой браузер» не совсем правда. Собственные сервисы — да, а вот всё остальное принадлежит другой компании(ям). И эта другая компания предоставляет свой браузерный движок на определенных условиях.
Лицензии браузерных движков
Любой открытый код содержит в себе лицензию с описанием условий по использованию данного кода, и браузерные движки не исключение.
Если сразу и кратко: лицензии сносные, прям вот из ряда вон ничего нет. Кроме EdgeHTML который закрыт. Легально утащить к себе какой-то проект и закрыто разрабатывать/изменять видимо не выйдет. Лицензии призывают к взаимной открытости.
Открытый исходный код, ответвление движка WebKit. Как и в WebKit заявлено четыре лицензии:
Самый популярный браузерный движок. Он входит в состав проекта Chromium. Именно на основе Chromium создают собственные браузеры.
Если верить файлу LICENSE проекта Chromium его основная лицензия 3-Clause BSD. Но у проекта есть директория third_party (третьи лица, третья сторона) содержащая множество стороннего кода от которого проект зависит. Иначе говоря, без этого кода собрать браузер не выйдет. У каждого компонента свои лицензии отличные от того что указано в LICENSE проекта:
Открытый исходный код. Заявлена одна лицензия:
Активно развивается компаний Mozilla и используется в собственном браузере компании — Firefox. Так же используется в браузере Tor Browser обеспечивающий анонимное пребывание в сети.
Как основа для производителей браузеров большой популярности не имеет.
Открытый исходный код. Заявлено четыре лицензии:
Развивается компанией Apple и используется в собственном браузере компании — Safari. Ранее многие компании использовали в своих разработках WebKit, но после покинули проект и переключились на Blink от Google.
Закрытый исходный код. Проприетарная лицензия.
Движок используется для браузера компании Microsoft под названием Edge, который пришёл на смену Internet Explorer. Это их новый движок. Предыдущий Trident (MSHTML) компания прекратила развивать.
Риски
Использование стороннего движка порождает очевидные риски:
Никто не может гарантировать, что исходный код свободного браузерного движка не будет закрыт для публичного доступа. Так же возможен выход ключевых компаний из разработки свободного движка, что фактически является его закрытием.
Компании развивающие собственные браузеры должны понимать, что всё будет «хорошо» пока они не составляют угрозу/конкуренцию разработчикам оригинального браузера/браузерного движка. Думаю это очевидно. Компания тратит на разработку движка свои ресурсы, но вдруг появляется другая компания которая используя их движок захватывает рынок. Реакция, думаю, очевидна — смотрим список рисков выше.
«Мы создадим копию движка на текущий момент и продолжим развивать сами» — именно так отвечают производители браузеров на сторонних движках. Большое заблуждение, не выйдет просто так продолжить разработку чужого движка. То есть, взять программистов и поставить им задачу — пишите браузерный движок. Написание браузерного движка сложный технологический процесс. Подтверждением этого служит список их обладателей.
Для примера, компания Microsoft создает свой движок, хоть и закрытый. Google вместе с Apple разрабатывали WebKit, но позже Google сделал форк и начал развитие собственного движка Blink.
При этом нужно понимать, что браузерный движок постоянно развивается. Постоянно обновляются спецификации, добавляются новые возможности, улучшаются текущие. Это живая работа. Если взять какой-либо движок на текущую дату и просто использовать его для своего браузера то, примерно, через год-два браузер на этом движке морально устареет.
Адаптация движков
Существует проблема адаптации стороннего движка под нужды собственного браузера. На адаптацию тратится не мало ресурсов. При этом нужно понимать, что браузерные движки часто обновляются, что создает систематические проблемы при интеграции в собственный браузер.
Собственный движок
Прежде всего стоит ответить на главный вопрос — зачем создавать свой браузерный движок? А точнее, кому не надо создавать свой движок?
Свой браузерный движок не стоит создавать если:
На текущий момент нет сложности создать собственный браузер на стороннем движке. Их наплодилось не мало и как-то выделиться среди всей этой массы можно только созданием браузера на исключительно своих компонентах, на собственном движке.
Стоит ли заниматься разработкой движка для «заработка», для создания стартапа?
Данный вопрос скорее к сфере его применения. Мне видится несколько направлений:
Кроме того, престиж компании разработчика браузерного движка значительно выше чем у клонов. Именно как технологической компании. Это сказывается на популярности компании и привлекательности для существующих и будущих сотрудников. Но это уже скорее о честолюбии, встать в одном списке с такими компаниями как Google, Mozilla, Microsoft.
Заключение
Без сомнения, создание браузерного движка процесс сложный и требующий значительных ресурсов. Подходить к этой разработки необходимо крайне серьёзно и с чётким планом по развитию. Кроме того, это не тот продукт прибыль от которого можно получать на промежуточном этапе разработки. Да, отдельные компоненты можно адаптировать под нужды компаний, но я уверен, что такой подход только отнимет время и значительно затянет разработку.
Развитие браузерного движка сильно зависит от метода его разработки. Каким он будет: открытым, закрытым?
Я уверен, что если компания занимается развитием браузера на основе стороннего браузерного движка то ей следует серьёзно подумать над перспективой создания собственного.
Компании далёкой от браузеров заняться разработкой браузерного движка тоже можно, и не только для того чтобы создать браузер. Если итоговый продукт будет полноценным браузерным движком превосходящим существующие то он будет востребован. Сферы применения были описаны выше.
Цикл статей
Судьба Modest
Кто-то из читателей, возможно, знает, что я занимаюсь разработкой браузерного движка. В моих публикациях можно найти предыдущие статьи на эту тему.
К сожалению, проект Modest пришлось завершить. Какое-то время проект развивался в компании, в которой я раньше работал. Мне пришлось покинуть компанию. Появились разногласия которые не позволили продолжить разработку проекта. Обычный рабочий процесс, такое бывает.
Не смотря на то, что у меня есть все права на Modest, на код никто не претендует (подписаны бумаги), я решил его «закопать». Чтобы ни у кого не возникало ложных ощущений. Тут надо понимать, что закапывается и весь основной код который развивался вне компании (mycore, myhtml). Но, есть и плюс, возможно, я стал чуть умнее.
Мной было потрачено очень много времени на изучение спецификаций, осознания их, поиск оптимальных алгоритмов, написание черновиков (прототипов), создание myhtml (самый быстрый парсер html) в свободное от работы время, и просто так забросить эту тему я пока не могу. Было потрачено много выходных, праздников, вечеров, ночей.
Теперь я занимаюсь разработкой нового браузерного движка. Разработка с ноля. Имени у него пока нет, только кодовое — lexbor. Вся основа уже написана: работа с памятью, общие алгоритмы, заложена будущая архитектура. Как всегда, всё краше и лучше чем было. В общем, у меня есть самое главное: технология и чёткое видение/понимание как и что развивать.
Одному мне такой проект не потянуть. Если поддержки не найду (финансирования) то прекращу разработку и присоединюсь контребьютером к существующему открытому движку (Blink или Gecko). Попробую побыть там волонтером и реализовать свои идеи. Занимаюсь всем этим исключительно в нерабочее время.
Тут видимо должна быть картинка «ты должен был бороться со злом, а не примкнуть к нему».