Александр Хованский опубликовал на хабре неплохую статью "Введение в Screen Capture API — Сканируем QR коды в браузере".

Автор статьи захотел написать приложение, с помощью которого можно распознавать qr-коды прямо на компьютере. Для этого он воспользовался Screen Capture API. Это API позволяет захватывать изображения с экрана монитора целиком, окна какого-то определённого приложения или определённой вкладки браузера (эта возможность доступна только в Chrome).

В статье есть пример кода захвата; он состоит из следующих частей:
1. Отправка потока в <video>
2. Периодическая отрисовка <video> в <canvas>
3. Захват изображения с помощью getImageData()

Ещё в статье есть ссылка на демо готового приложения. Проверил — всё работает замечательно. Но стоит иметь в виду, что Screen Capture API поддерживают только Firefox, Chrome и Edge.

#web #api #tutorial

https://habr.com/ru/post/460825/

В блоге web.dev была опубликована статья про изолированные окружения — "Making your website "cross-origin isolated" using COOP and COEP".

В web-платформе есть потенциально небезопасные, но мощные API: SharedArrayBuffer (требуется для WebAssembly Threads), performance.measureMemory (будет доступно в Chrome 83) и JS Self-Profiling API (пока нет поддержки в браузерах). Чтобы понять насколько опасно может быть их использование, можно вспомнить 2018 год, когда SharedArrayBuffer использовался для реализации атаки Spectre. Как противодействие Spectre SharedArrayBuffer был по умолчанию отключён во всех браузерах.

Для получения возможности использовать эти API ребята из Google разработали концепцию изолированного окружения (cross-origin isolated environment). Чтобы его включить, нужно отправить с документом http-заголовки:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Изолированное окружение (cross-origin isolated environment) полностью запрещает доступ к странице сторонним скриптам через window.opener или iframe и отключает изменение свойства document.domain. Благодаря чему семейство атак по сторонним каналам (например, Spectre) перестают работать.

Включение COOP и COEP на больших сайтах может быть нетривиально, поэтому в статье есть инструкции, как найти и исправить возникшие проблемы. Поддержка изолированных окружений ожидается в Chrome 83.

#security #api

https://web.dev/coop-coep/

Томас Штейнер из Google опубликовал пост про новое API — "The requestVideoFrameCallback API".

Метод requestVideoFrameCallback() находится у элемента <video>. Он позволяет регистрировать колбэк, который будет выполняться при отправке каждого кадра видеопотока в композитор, то есть на этапе рендеринга изображения. Эта фича предназначена для эффективной обработки видео в браузере, для синхронизации с внешними звуковыми источниками, для видео-анализа и "зеркалирования" видео в canvas. Частота, с которой вызывается колбэк, минимальное значение от частоты экрана и частоты кадров видео.

На данный момент поддержка requestVideoFrameCallback API есть только в Chromium, разработчики Firefox тоже заинтересованы в реализации этой фичи. Если всё взлетит, то вполне возможно, что через пару лет в браузере будет работать Adobe Premiere.

#video #api

https://blog.tomayac.com/2020/05/15/the-requestvideoframecallback-api/

Джек Арчибальд написал статью "Event listeners and garbage collection". В ней рассказывается про способ прерывания любого асинхронного API и объясняется, почему этот способ не приводит к утечкам памяти.

Все современные браузеры поддерживают отмену fetch-запросов с помощью AbortController API. В статье есть код небольшого хелпера, который позволяет использовать AbortController с любым асинхронным API:

async function abortable(signal, promise) {
  if (signal.aborted) {
    throw new DOMException('AbortError', 'AbortError');
  }
  return Promise.race([
    promise,
    new Promise((_, reject) => {
      signal.addEventListener('abort', () => {
        reject(new DOMException('AbortError', 'AbortError'));
      });
    }),
  ]);
}

В нём используется обработчик события "abort", который вызвал подозрение у читателя Джека. В статье очень подробно объясняется, почему этот обработчик не приводит к утечке — при завершении работы асинхронного кода функция удаляется из стека выполнения, поэтому все объекты, которые были связаны с этой функцией, без проблем удаляются сборщиком мусора.

Очень хорошая статья. Рекомендую посмотреть примеры, особенно если вы раньше не работали с AbortController.

#web #api

https://jakearchibald.com/2020/events-and-gc/

Сурма написал статью про новое расширение ResizeObserver, с помощью которого можно получить размер элемента в физических пикселях — "Pixel-perfect rendering with devicePixelContentBox".

Иногда возникают ситуации, в которых размеры блока в пикселях могут получаться дробными. При рендеринге таких элементов CSS-пиксели "подгоняются" браузером к физическим пикселями с помощью pixel snapping. Проблема в том, что не было надёжного способа получения размера элемента в реальных физических пикселях. Из-за этого невозможно было реализовать pixel-perfect отрисовку в canvas — изображения могли получаться нечёткими, на них мог проявляться эффект Муара.

В Chrome 84 была добавлена новая опция ResizeObserver ['device-pixel-content-box']. С её помощью можно получить размер любого элемента в физических пикселях и добиться pixel-perfect рендернига canvas.

#rendering #api

https://web.dev/device-pixel-content-box/

Рйо Ота рассказал, как можно сделать SSH-клиент, VNC-клиент и мессенджер без использования веб сокетов и WebRTC — "The Power of Pure HTTP – screen share, real-time messaging, SSH and VNC".

Обычно HTTP используется для передачи относительно небольших объёмов данных. Разработчики браузеров сейчас работают над возможностью отправки по сети ReadableStream с помощью fetch, то есть создания канала для передачи бесконечного потока данных. В статье разбираются примеры, как использовать эту фичу вместе с piping server, который позволяет организовать взаимодействие между двумя браузерами с помощью обычных GET- и POST-запросов. С помощью такого подхода можно сделать приложение просмотра удалённого рабочего стола, SSH-клиенты и другие подобные приложения, которые работают внутри браузера и используют обычный HTTP-канал в качестве транспорта.

На данный момент возможность передачи ReadableStream с помощью fetch есть только в Chrome в экспериментальном режиме.

#experimental #http #api

https://dev.to/nwtgck/the-power-of-pure-http-screen-share-real-time-messaging-ssh-and-vnc-5ghc

Андрей Мелихов на канале ДевШахты рассказал про Server-Sent Events API — "Server-Sent Events: Простая замена веб-сокетов".

Если вам нужно читать данные с сервера в реальном времени, то не обязательно для этого использовать веб-сокеты. Для этой цели хорошо подходит Server-Sent Events API (SSE API). В отличие от веб-сокетов он используется для создания однонаправленного канала связи с сервером и не так сложен в использовании.

Для работы с SSE на клиенте используется класс EventSource, которому нужно передать url сервера. Сервер в свою очередь должен отправлять поток данных с метаинформацией обычным текстом, так как SSE работает поверх HTTP. Поддержка SSE есть во всех современных браузерах.

Рекомендую посмотреть видео, если раньше не приходилось работать с SSE.

#api #video

https://www.youtube.com/watch?v=CJrmK3IXC8o

Андрей Мелихов на канале ДевШахты опубликовал вторую часть видео, посвящённую Server-Sent Events — "Server-Sent Events: Снимаем ограничения".

В первой части Андрей рассказывал про основные концепции использования API и про решаемые ей задачи (простая альтернатива веб-сокетам, однонаправленный канал связи с сервером). Вторая часть посвящена использованию SSE в реальных проектах.

При использовании SSE поверх первой версии HTTP есть ограничение на максимальное количество подключений к источнику данных — в рамках одной страницы нельзя сделать больше шести подключений. Эту проблему можно обойти переходом на HTTP/2. Также при создании подключения с помощью конструктора EventSource нет возможности передать дополнительные HTTP-заголовки, например, для авторизации. Это ограничение можно обойти с помощью кук.

Рекомендую посмотреть видео, если хотите узнать больше подробностей про нюансы работы с SSE.

#api #nodejs #video

https://www.youtube.com/watch?v=v6Fc4FQwNa4

Томас Штайнер написал статью про Storage Foundation API — "High performance storage for your app: the Storage Foundation API".

Современные веб-приложения не могут эффективно и гибко работать с большими массивами данных, сохранёнными на диске, что особенно критично для баз данных и программ редактирования аудио и видео.

Эту проблему призван решить Storage Foundation API. Он предоставляет средства для производительной работы с хранилищем данных и включает в себя набор примитивов, работа с которыми напоминает работу с обычной файловой системой. С его помощью можно получать информацию о доступном месте, создавать/удалять/переименовывать файлы, производить запись/чтение данных со смещением и т.п.

На данный момент экспериментальная поддержка Storage Foundation API есть только в Chrome в рамках программы Origin Trial.

#api #chrome #experimental

https://web.dev/storage-foundation/

Бесшовные переходы между экранами SPA с помощью shared element transition API

Джейк Арчибальд рассказал о новом пропозале для создания бесшовных переходов между экранами SPA — "Smooth and simple page transitions with the shared element transition API".

Бесшовные переходы сложны в реализации. При их создании нужно обеспечить плавность анимации, корректность обработки событий при изменении состояний и убедиться в том, что одновременное присутствие двух экранов не ломает доступность.

Эти проблемы призван решить shared element transition API. С его помощью можно легко создавать простые переходы между экранами и сложные переходы с разделяемыми элементами. Вот так реализуется простой переход:

async function navigateToSettingsPage() {
  await document.documentTransition.prepare({
    rootTransition: 'cover-left',
  });
  updateDOMForSettingsPage();
  await document.documentTransition.start();
}

Shared element transition API пока доступен в Chrome в экспериментальном режиме. Также на данный момент его можно использовать только в рамках одной страницы, но у авторов спецификации есть планы по его расширению для обеспечения бесшовных переходов между разными страницами сайта.

#chrome #api #spa

https://developer.chrome.com/blog/shared-element-transitions-for-spas/

Взаимодействие с веб-воркером без прерывания цикла событий

Михай Парпарита поделился эффективным способом общения с веб-воркером без использования SharedArrayBuffer — "Communicating With a Web Worker Without Yielding To The Event Loop".

Автор статьи работал над веб-версией эмулятора ОС старых Макинтошей. Архитектура эмулятора разделена на две основные части: UI и поток эмуляции, работающий в веб-воркере. Чтобы эмуляция работала плавно, для обмена данными между UI и веб-воркером используется SharedArrayBuffer. Поддержка SharedArrayBuffer на данный момент отключена в Safari. Михай нашёл альтернативное решение.

Веб-воркер может подгружать дополнительный код с помощью importScrips. importScripts работает синхронно, открывая возможность передачи команд из основного потока с помощью динамически формируемого JavaScript-кода. JavaScript-код создаётся внутри сервис-воркера и сохраняется в файл, который в цикле загружается в веб-воркере.

Такой подход медленнее SharedArrayBuffer, но быстрее решения с остановкой цикла событий и позволяет достичь хорошей отзывчивости ввода в эмуляторе.

#api #webworkers

https://blog.persistent.info/2021/08/worker-loop.html