В Electron 44.6.0 появился экспериментальный API protocol.registerSource(), который позволяет отдавать файлы приложения через собственную схему без JavaScript-обработчика в главном процессе. В тесте команды Electron страница с 60 таблицами стилей при занятом main process загружалась за 14 мс против 120 мс через protocol.handle().
Electron 44.6.0 переносит раздачу локальных файлов с main process на уровень сетевого стека
У десктопных приложений на Electron часто есть собственная схема вроде app://. Через неё приложение может загружать HTML, JavaScript, CSS, изображения и другие ресурсы из своего дистрибутива. До версии 44.6.0 один из распространённых способов строился вокруг protocol.handle(): каждый запрос проходил через JavaScript-обработчик в главном процессе Electron.
Здесь и появлялась неприятная зависимость. Если main process занят запуском приложения, инициализацией модулей или другой синхронной работой, запросы к ресурсам ждут своей очереди. В результате окно уже создано, но его интерфейс может загружаться медленнее именно в тот момент, когда главный процесс сильнее всего загружен.
В 44.6.0 команда Electron добавила экспериментальные методы protocol.registerSource() и protocol.getSource(). Новый механизм позволяет заранее описать, из каких каталогов обслуживается собственная схема. После регистрации маршруты обрабатываются внутри сетевого стека Electron, а чтение файлов уходит с главного потока.
Разница особенно заметна в тесте, который разработчики приложили к изменению. На Linux x64 использовалась страница с 60 таблицами стилей. Медианное время тёплой загрузки через protocol.handle() составило 22 мс при свободном main process и 120 мс, когда главный процесс искусственно занимали на 100 мс после начала навигации. С protocol.registerSource() те же измерения дали 13 и 14 мс.
Для отдельного fetch() команда получила сокращение времени кругового запроса примерно с 0,33 до 0,20 мс. Затраты CPU в browser process снизились с 234 до 200 микросекунд на запрос, а участие main thread в такой загрузке исчезло.
protocol.registerSource поддерживает маршруты, ASAR, Range-запросы и защиту корневого каталога
protocol.registerSource() рассчитан на приложения, которые хранят интерфейс и статические ресурсы внутри собственного пакета. Разработчик описывает набор маршрутов, где можно сопоставить host и префикс пути с конкретным каталогом.
Если для одного URL подходят несколько правил, Electron сначала выбирает совпадение по host, затем самый длинный префикс пути. Файлы могут находиться как в обычном каталоге, так и внутри ASAR-архива.
В реализацию сразу вошли проверки границ корневого каталога. Пути канонизируются при регистрации, а запрошенный файл разрешается с учётом символических ссылок. Ресурс за пределами указанного root через такой маршрут не выдаётся.
Механизм понимает GET и HEAD, формирует Content-Type по расширению файла, поддерживает Range и возвращает 206 Partial Content для корректного диапазона. Для недопустимого диапазона предусмотрен ответ 416, а обычные файлы размером свыше 4 ГиБ больше не проходят через прежнее 32-битное ограничение структуры, которая использовалась для ASAR.
API пока отмечен как experimental. Внутри одной схемы используется либо JavaScript-handler, либо зарегистрированный source. protocol.unhandle() удаляет оба варианта, а protocol.isProtocolHandled() учитывает и handler, и source.
webview.findInPage больше не должен зацикливаться рядом с iframe
Второе заметное исправление касается <webview>. В определённой структуре страницы поиск через findInPage() мог зависнуть, если страница-хозяин одновременно содержала обычный <iframe>.
Причина была в обходе дерева фреймов Chromium. При переходе между внутренним WebContents и соседними фреймами код мог возвращаться к уже посещённым узлам. Главный поток браузерного процесса начинал крутиться внутри FindRequestManager::Traverse(). Событие found-in-page переставало приходить, и поиск фактически зависал.
Electron 44.6.0 меняет способ определения соседних фреймов: они вычисляются через набор дочерних элементов общего предка. Команда добавила тест со страницей, где одновременно присутствуют iframe и webview, а поиск проходит три совпадения и корректно возвращается к первому.
Для приложений, которые используют <webview> как встроенный браузер, просмотрщик документации, почтовый клиент или оболочку для внешнего контента, это исправление убирает сценарий, способный заблокировать поиск по странице и загрузить main thread браузерного процесса.
WebUSB в in-memory sessions больше не падает при requestDevice
Electron также исправил сбой при вызове navigator.usb.requestDevice() в сессиях, которые существуют только в памяти. Такой режим появляется, например, при создании BrowserWindow с partition без префикса persist:.
Проблема находилась в UsbChooserContextFactory. Для off-the-record контекста не создавался собственный UsbChooserContext, после чего контроллер выбора USB-устройства мог обратиться к пустому указателю.
В 44.6.0 in-memory session получает собственный контекст USB по той же логике, которая уже применяется для HID и Serial. В тестах команда проверяет и navigator.usb.getDevices(), и сам вызов requestDevice() в отдельном временном partition.
Изменение касается приложений, работающих с периферией через WebUSB: конфигуратора оборудования, сервисных утилит, терминалов и специализированных корпоративных клиентов, где временные профили позволяют разделять состояние разных окон или пользователей.
macOS переживёт ошибку регистрации системного power monitor без аварийного завершения
Ещё один фикс пришёл из Chromium и связан с macOS. При инициализации PowerMonitorDeviceSource системный вызов IORegisterForSystemPower() способен завершиться ошибкой и вернуть MACH_PORT_NULL.
Ранее дальнейшая инициализация могла обратиться к отсутствующему notification port и завершить процесс аварийно. В новой логике Electron продолжает запуск с ограниченной функциональностью: наблюдатели suspend/resume в такой ситуации не получают события, при этом независимый мониторинг батареи и температурного состояния продолжает инициализироваться.
Исправление затрагивает низкоуровневую часть Electron, поэтому пользователь приложения обычно не видит сам механизм. Видимым следствием старого поведения мог быть ранний краш приложения на macOS во время старта.
Electron получил tzdata 2026d раньше очередного обновления ICU в Chromium
В тег 44.6.0 вошло обновление базы часовых поясов ICU до tzdata 2026d. В ветке Chromium, на которой основан Electron 44, оставалась база 2025c, поэтому в ней отсутствовали отдельные новые региональные правила.
В описании коммита разработчики приводят Британскую Колумбию: регион переходит на постоянный UTC−7 с 1 ноября 2026 года. Без свежей tzdata приложение могло получить устаревшее представление о локальном времени для затронутых регионов.
Electron решил вопрос отдельным патчем ICU в своей ветке. Для календарей, мессенджеров, систем планирования, журналов событий и приложений с часовыми поясами такая правка влияет на преобразование локального времени и отображение дат после изменения региональных правил.
Chromium 152 и Node.js 24.21.0 сохраняются в ветке Electron 44.6.0
Файл зависимостей тега v44.6.0 указывает Chromium 152.0.7977.130 и Node.js 24.21.0. Эти версии совпадают с предыдущей стабильной сборкой 44.5.x, поэтому основной технический сдвиг 44.6.0 связан с изменениями самого Electron и его патчами поверх Chromium.
В ветке обновили и собственные PGO-профили Electron для Linux arm64/x64, macOS arm64/x64, Windows arm64/x64 и встроенных частей V8. PGO, или profile-guided optimization, использует данные реального выполнения программы, чтобы компилятор лучше расположил и оптимизировал часто исполняемый код.
Ещё несколько коммитов в промежутке между 44.5.1 и 44.6.0 относятся к тестовой инфраструктуре: стабилизированы проверки fullscreen, pointer lock и восстановления состояния страниц. Они не создают новых API для приложений, но уменьшают случайные падения тестов самого Electron на macOS.
Тег v44.6.0 уже создан, а официальный статус сборки ещё проходит финальные стадии
Тег v44.6.0 появился в официальном репозитории Electron 5 октября 2026 года. Исходный архив версии уже доступен, а код релиза зафиксирован коммитом, включающим обновление tzdata 2026d.
При проверке утром 6 октября официальный сервис Electron Releases всё ещё показывал v44.6.0 в разделе Active Builds со статусом Building. Linux и Windows на странице статуса уже были отмечены как completed, macOS оставался на стадии сборки. Там же перечислены дальнейшие этапы: валидация, публикация на GitHub, публикация в npm и финализация.
Получилась редкая промежуточная ситуация: содержимое версии уже можно точно разобрать по официальному тегу, при этом автоматизированная публикация всех бинарных артефактов ещё завершалась. После финализации статус Electron 44.6.0 должен перейти из Active Builds в обычный список стабильных релизов.
Да, его нужно было добавить. Для статьи можно использовать такой блок:
