Microsoft Edge 155: підтримка декодування JPEG XL

Microsoft випустила Edge 155 для Windows, macOS і Linux. Браузер отримав підтримку декодування JPEG XL, а обробники `unload` тепер за замовчуванням не запускаються.

· 4 хв читання · 5 коментарів

8 жовтня 2026 року Microsoft випустила стабільну версію Edge 155 для Windows 10/11, macOS і Linux. Як пише Хабр, оновлення містить виправлення помилок і вразливостей безпеки, нові політики та підтримку декодування JPEG XL. Для команд, які підтримують сайти, особливо важливі зміни в роботі із зображеннями та подією unload.

JPEG XL і поведінка сторінок під час виходу

Edge 155 навчився декодувати зображення JPEG XL. Це має значення для сайтів, які вже використовують цей формат або розглядають його для своїх матеріалів. Але з одного повідомлення про підтримку в Edge не можна робити висновок про сумісність зображень для всієї аудиторії сайту: матеріал не описує, як їх обробляють інші браузери. Тему доповнює новина про підтримку JPEG XL у Chrome 155.

Друга зміна стосується події unload. Edge поступово вимикав запуск її обробників за замовчуванням, залишаючи сайтам можливість явно дозволити їхню роботу через Permissions Policy. У версіях 152 і 153 нова поведінка поширювалася на 60% завантажень сторінок, у версії 154 — на 80%. В Edge 155 цей показник сягнув 100%. Це не означає, що дозволити роботу обробника тепер неможливо, але розраховувати на його запуск без явного дозволу вже не можна.

Для розробників це привід переглянути дії, прив’язані до виходу користувача зі сторінки. Якщо важлива частина логіки спирається саме на unload, колишню поведінку в Edge більше не можна сприймати як належне. У матеріалі розробникам пропонують використовувати відповідні події життєвого циклу та API. Зміна не обмежується одним випуском браузера: у перспективі вебплатформа рухається до повної відмови від unload.

Безпека, вкладки та плани на наступні версії

Edge 155 містить виправлення вразливостей безпеки проєкту Chromium, а також патчі для вразливостей самого Edge. Окремі вразливості матеріал не перелічує, тому оцінити за ним вплив конкретного виправлення на сайт чи пристрій не можна. Крім виправлень безпеки, оновлення містить виправлення помилок і нові політики.

Microsoft розвиває інструменти для впорядкування вкладок і робочих областей. Серед доступних можливостей — групування, назви, візуальне оформлення та мітки. Користувач керує ними через налаштування «Дозволити Microsoft Edge допомагати впорядковувати вкладки» в edge://settings/privacy/services. Адміністратори можуть використовувати для цього політику TabServicesEnabled.

Частина змін стосується наступних випусків. Перехід із застарілого прямого входу через Windows Web Account Manager на OneAuth мають завершити в Edge 157. При цьому WAM залишиться всередині системи; деяким користувачам може знадобитися знову ввійти в браузер. Це зміна способу входу, а не припинення підтримки WAM.

Переклад відео в реальному часі більше не підтримується, а політику LiveVideoTranslationEnabled приберуть в одному з майбутніх оновлень. Термін видалення політики LocalNetworkAccessRestrictionsTemporaryOptOut, навпаки, перенесли: тепер це планують зробити після Edge 163, тоді як раніше йшлося про період після версії 156.

Із кінця серпня 2026 року Edge випускають раз на два тижні замість раніше запланованого чотиритижневого циклу. За такого графіка корисно розрізняти поведінку, яка вже діє у версії 155, і зміни, для яких поки названо лише майбутні терміни.

Що перевірити команді сайту

Якщо сайт використовує JPEG XL або команда лише планує його застосовувати, варто перевірити потрібні сторінки та зображення в Edge 155. Підтримка декодування підтверджує, що браузер може працювати з форматом, але не замінює перевірки сценаріїв і браузерів, важливих для конкретного сайту. Якщо JPEG XL у проєкті немає і його впровадження не обговорюють, окремо перевіряти формат через цей випуск не потрібно.

Інша перевірка стосується сторінок, де код залежить від unload. Потрібно з’ясувати, чи є такі сценарії та що відбувається, коли користувач залишає сторінку в оновленому Edge. Без явного дозволу сайту обробник за замовчуванням не запускається вже для 100% завантажень сторінок. Якщо від цієї події залежить потрібна дія, розробникам доведеться переглянути її реалізацію з урахуванням подій життєвого циклу та відповідних API.

Власникам сайтів і маркетологам необов’язково самостійно розбиратися в Permissions Policy чи налаштуваннях браузера. Достатньо уточнити в команди, чи використовуються на сайті JPEG XL і unload, а потім домовитися про перевірку саме тих сторінок, яких стосуються зміни. Таке обговорення допомагає не змішувати питання сумісності зображень зі зміною поведінки сторінки: ці завдання мають різні умови та способи перевірки.

Моя думка

Я б почала з одного важливого користувацького сценарію: коли команда разом дивиться на конкретну робочу сторінку, простіше домовитися, що справді потрібно виправити, а що поки залишається лише припущенням. Така розмова пов’язує макет, поведінку інтерфейсу й можливості реалізації, не вимагаючи одразу переглядати весь сайт.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

  1. Релиз Microsoft Edge 155 habr.com

Про автора

Аліна Опря

артдиректорка цифрових продуктів

Проєктую інтерфейси й допомагаю командам домовитися про візуальну систему. Якщо є сумніви, можна почати з одного екрана й перевірити його на реальних людях.

Усі публікації автора

Бекенд 3 хв читання

Next.js випустив оновлення безпеки для гілок 15.5 і 16.3

Next.js випустив версії 16.3.8 і 15.5.27, що усувають уразливості кешування, розкриття даних та оптимізації зображень. Командам рекомендують оновити застосунки й перевірити функції, які вони використовують.

Написати коментар

Не публікується. Надішлемо посилання, щоб підтвердити коментар.

Без посилань і реклами. Перший коментар публікується після перевірки. Надсилаючи коментар, ви погоджуєтеся з політикою конфіденційності.

  1. Не погоджуся з думкою, що підтримку JPEG XL в Edge вже можна вважати достатньою підставою переводити на нього зображення сайту. Важливо не лише те, чи браузер декодує формат, а й чи є fallback для решти аудиторії та чи не ламається завантаження в різних сценаріях; це краще перевірити окремо, перш ніж міняти пайплайн.

    1. У навчальному проєкті вже ловив схожу штуку: картинка нормально відкривалась у моєму браузері, а в іншому сценарії сторінка лишалась без зображення, бо fallback не перевірив. Тож для JPEG XL я б спершу додав запасний формат і поганяв завантаження з різними браузерами та кешем — звучить як хороший маленький тест перед зміною пайплайну 🙂

      1. @vazir.s, кеш тут теж важливий, але уточню: fallback для JPEG XL краще перевірити окремо від кешу — наприклад, завантажити сторінку в браузері без підтримки формату й переконатися, що запасне зображення справді показується. У тебе проблема була саме через кеш чи через відсутність fallback?

        1. Аліна Опря Автор публікації

          @kestutis.sakalauskas, схоже, причина була саме у відсутності fallback: у моєму сценарії запасне зображення не було налаштоване, тож перевірити вплив кешу окремо не вдалося.

        2. @kestutis.sakalauskas, у його прикладі причина була саме у відсутності fallback: у різних сценаріях браузерів картинка не відображалась; кеш він згадав як окрему перевірку.