Закрыть проверенные pending-фичи
This commit is contained in:
AidarKC
parent
c048347f2e
commit
1ced351ea2
@ -74,11 +74,6 @@
|
|||||||
- Подробный рабочий регламент: `Dev_Docs/Figma/TRANSFER_UI_SCREENS.md`.
|
- Подробный рабочий регламент: `Dev_Docs/Figma/TRANSFER_UI_SCREENS.md`.
|
||||||
- Для экранов регистрации, входа и других чувствительных UI-flow по умолчанию переносить экраны в Figma по одному, а не пачкой, если пользователь отдельно не подтвердил иной способ.
|
- Для экранов регистрации, входа и других чувствительных UI-flow по умолчанию переносить экраны в Figma по одному, а не пачкой, если пользователь отдельно не подтвердил иной способ.
|
||||||
|
|
||||||
## Известная проблема (временная пометка)
|
|
||||||
- Мнения по связям пользователя (`known_person`, `shine_confirmed`, `shine_seen`) в UI могут отображаться нестабильно.
|
|
||||||
- Требуется отдельная доработка и финальная проверка end-to-end: запись мнения в блокчейн → обновление `connections_state` → ответ `GetUserConnectionsGraph` → отображение в UI.
|
|
||||||
- До фикса считать эту часть функционала незавершённой и обязательно перепроверять вручную после каждого деплоя.
|
|
||||||
|
|
||||||
## Версионирование
|
## Версионирование
|
||||||
- Единый файл версий проекта: `VERSION.properties` (в корне репозитория).
|
- Единый файл версий проекта: `VERSION.properties` (в корне репозитория).
|
||||||
- Перед каждым новым коммитом обязательно увеличивать версии в `VERSION.properties`:
|
- Перед каждым новым коммитом обязательно увеличивать версии в `VERSION.properties`:
|
||||||
|
|||||||
@ -1,22 +0,0 @@
|
|||||||
# Быстрое скрытие экрана звонка и остановка гудков при отклонении
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- Исправлена нижняя подпись вкладки личных сообщений на `личные`.
|
|
||||||
- Исправлена логика звонка, когда одна из входящих сессий отклоняет вызов до принятия: исходящая сессия теперь должна прекращать гудки даже если ранее `RINGING` пришёл от другой входящей сессии.
|
|
||||||
- На устройстве, где пользователь нажимает отмену/сброс звонка, экран вызова теперь скрывается сразу локально, без ожидания сетевого ответа.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
- В нижней панели с 5 кнопками подпись первой кнопки должна отображаться как `личные`.
|
|
||||||
- Сценарий: один пользователь звонит, у второго входящий вызов приходит на несколько устройств; на любом одном входящем устройстве нажать `Сбросить`.
|
|
||||||
- Проверить, что у звонящего сразу прекращаются гудки и экран вызова корректно завершается.
|
|
||||||
- Проверить, что на устройстве, где нажали `Сбросить` или `Положить трубку`, overlay звонка исчезает сразу, без заметной задержки.
|
|
||||||
- Проверить, что после принятия звонка на одном устройстве поздние отмены с других устройств не ломают уже выбранную пару соединения.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- Подпись в нижней панели корректная.
|
|
||||||
- При отклонении входящего звонка любым устройством звонящего не оставляет в состоянии бесконечных гудков.
|
|
||||||
- Локальный экран звонка скрывается мгновенно после нажатия кнопки отмены.
|
|
||||||
- Уже зафиксированный сценарий соединения после `ACCEPT` не сбивается другими сессиями.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- `pending`
|
|
||||||
@ -1,14 +0,0 @@
|
|||||||
# Отключение устаревшего TURN-узла `45.136.124.227`
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- из конфигурации звонков убран устаревший TURN-узел `45.136.124.227:3478`;
|
|
||||||
- основным и единственным выдаваемым TURN-узлом оставлен `93.170.12.154:3478`.
|
|
||||||
- что проверять:
|
|
||||||
- сделать несколько тестовых звонков между разными устройствами/сетями;
|
|
||||||
- убедиться, что звонок доходит до стадии соединения и появляется звук;
|
|
||||||
- убедиться, что в логах `CallDeliveryReport` больше не фигурирует `45.136.124.227`.
|
|
||||||
- ожидаемый результат:
|
|
||||||
- клиентам больше не выдаётся устаревший TURN-адрес;
|
|
||||||
- звонки не заваливаются из-за попыток использовать отключённый TURN-узел.
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,15 +0,0 @@
|
|||||||
# Фикс самообрыва звонка из-за `stop_call` push своей же сессии
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- исправлена ситуация, когда активный звонок мог оборваться сразу после соединения;
|
|
||||||
- причина была в том, что `stop_call` push, предназначенный для других сессий того же пользователя, обрабатывался и в исходной сессии.
|
|
||||||
- что проверять:
|
|
||||||
- открыть несколько вкладок/устройств одного пользователя;
|
|
||||||
- принять звонок на одной сессии;
|
|
||||||
- убедиться, что активная сессия не обрывает звонок сразу после соединения;
|
|
||||||
- убедиться, что лишние сессии при этом закрывают свой локальный экран звонка.
|
|
||||||
- ожидаемый результат:
|
|
||||||
- звонок не завершается сразу после `call_connected`;
|
|
||||||
- `accepted_on_other_device` и связанные `stop_call` события больше не убивают исходную активную сессию.
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,16 +0,0 @@
|
|||||||
# Фикс привязки call push к целевой sessionId
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- push-события `incoming_call` и `stop_call` теперь помечаются целевой `sessionId`;
|
|
||||||
- UI и service worker обрабатывают call push только для своей целевой сессии;
|
|
||||||
- `stop_call` для лишних сессий закрывает локальный экран тихо, без обратных сигналов и без лишних тех-сообщений.
|
|
||||||
- что проверять:
|
|
||||||
- держать несколько сессий одного пользователя в одном браузере/на одном origin;
|
|
||||||
- позвонить этому пользователю и убедиться, что входящий экран закрывается корректно только на целевых сессиях;
|
|
||||||
- после `ACCEPT` одной сессии остальные должны тихо убрать экран вызова и не ломать выбранную пару;
|
|
||||||
- после отмены входящей сессией исходящая сессия должна централизованно завершить сценарий.
|
|
||||||
- ожидаемый результат:
|
|
||||||
- push одного session endpoint больше не влияет на чужие сессии этого же origin;
|
|
||||||
- исчезают ложные `stop_call_push:accepted_on_other_device` и `terminal_call_signal_150` на неправильных сессиях.
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
# ESP32 homeserver: заявки на подключение устройств
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- на ESP32 homeserver в `SETTINGS` добавлен первый пункт `Device requests`, который появляется только после авторизации homeserver в SHiNE;
|
|
||||||
- экран показывает список активных pairing-заявок, позволяет открыть каждую заявку и подтвердить или отклонить её;
|
|
||||||
- формат кода подключения изменён на `10` цифр и показывается как `5` пар.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
- на обычном клиенте и в wallet-plugin код отображается как `XX XX XX XX XX`;
|
|
||||||
- на доверенном веб-клиенте экран `Подключить по коду` показывает все активные заявки без поля ручного ввода;
|
|
||||||
- на ESP32 после успешной homeserver-авторизации в `SETTINGS` появляется пункт `Device requests` первым;
|
|
||||||
- `REFRESH` реально загружает активные заявки;
|
|
||||||
- на экране видно две плитки, список листается вертикально;
|
|
||||||
- client-session заявка после `YES` подключается с передачей только `client key`;
|
|
||||||
- wallet-session заявка после `YES` подключается без передачи ключей, через выпуск отдельной wallet-session;
|
|
||||||
- `NO` отклоняет заявку и она исчезает из списка активных.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- все три клиента используют единый формат кода;
|
|
||||||
- активные заявки видны без ручного ввода кода;
|
|
||||||
- ESP32 может одобрять и отклонять живые pairing-заявки пользователя.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,19 +0,0 @@
|
|||||||
# Исправление chatId личных сообщений через lowercase
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- В клиентском UI SHiNE для личных сообщений технический `chatId` теперь канонизируется через `trim().toLowerCase()` при приёме DM, открытии чата и восстановлении сообщений из IndexedDB.
|
|
||||||
- Цель: исключить рассинхрон, когда unread-индикатор есть, а входящие сообщения конкретного собеседника не видны из-за разного регистра логина.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
- Отправить личные сообщения между двумя пользователями, у одного из которых логин отображается с заглавными буквами.
|
|
||||||
- Убедиться, что входящие сообщения показываются внутри открытого чата, а не только в общем unread-индикаторе.
|
|
||||||
- Перезагрузить страницу и проверить, что история чата после гидрации из IndexedDB остаётся в одном диалоге.
|
|
||||||
- Проверить, что переход в чат из списка диалогов и из графа связей открывает тот же диалог без дублирования.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- Все сообщения одного собеседника попадают в один и тот же DM-чат независимо от регистра логина.
|
|
||||||
- Общий unread, список диалогов и содержимое открытого чата совпадают между собой.
|
|
||||||
- После перезагрузки UI не появляется отдельный дубль диалога с тем же логином в другом регистре.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,27 +0,0 @@
|
|||||||
# ESP32 выбор кошелька и wallet RPC для browser extension
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- в ESP32 заменён домашний блок `баланс + QR` на единый вход в экран кошелька;
|
|
||||||
- добавлен выбор активного кошелька `ClientKey / RootKey / Custom`;
|
|
||||||
- для browser extension добавлен первый RPC `get_wallet_public_key` через существующий `wallet-session` и `CallSignalToSession`;
|
|
||||||
- в popup расширения добавлен запрос текущего кошелька и копирование `publicKeyBase58`.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
- на ESP32 после ввода секрета на главном экране видна кнопка `Кошелёк: ...`;
|
|
||||||
- экран `WALLET` открывается и показывает текущий тип кошелька;
|
|
||||||
- экран `WALLET_SELECT` переключает `ClientKey`, `RootKey` и `Custom`;
|
|
||||||
- для `Custom` открывается ввод имени и после сохранения derivation работает;
|
|
||||||
- `Показать баланс кошелька` читает баланс именно активного кошелька;
|
|
||||||
- `Показать QR-код кошелька` показывает QR и адрес именно активного кошелька;
|
|
||||||
- browser extension после подключения wallet-session может запросить текущий кошелёк у ESP32;
|
|
||||||
- extension показывает тип кошелька, полный `publicKeyBase58`, результат проверки через PDA и копирует ключ в буфер;
|
|
||||||
- для `client.key` и `root.key` проверка через PDA даёт ожидаемое совпадение.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- активный кошелёк на ESP32 реально влияет на баланс, QR и ответ `get_wallet_public_key`;
|
|
||||||
- browser extension получает ответ без ручного ввода `walletSelector`;
|
|
||||||
- homeserver выбирается из опубликованных в PDA sessions и запрос приходит в нужное устройство;
|
|
||||||
- копирование ключа из extension работает.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,18 +0,0 @@
|
|||||||
# ESP32 English UI and trusted login fix
|
|
||||||
|
|
||||||
- Краткое описание:
|
|
||||||
переведён экранный UI ESP32 homeserver на английский язык; добавлена локальная инструкция для AGENTS по ограничению кириллицы; исправлено падение `StartTrustedDeviceLogin`, когда у пользователя ещё нет записи `esp_pairing_settings`.
|
|
||||||
|
|
||||||
- Что проверять:
|
|
||||||
1. На ESP32 открыть `HOME`, `WALLET`, `SELECT WALLET`, `WALLET QR` и убедиться, что пользовательские строки на экране только на английском.
|
|
||||||
2. Проверить сценарий выбора `ClientKey`, `RootKey`, `Custom` и чтение баланса/QR после переключения.
|
|
||||||
3. В расширении открыть popup, запустить `Подключить` для логина, у которого ещё не настраивался trusted-device login.
|
|
||||||
4. Убедиться, что `StartTrustedDeviceLogin` больше не падает с `NullPointerException`.
|
|
||||||
5. После создания pairing-запроса проверить, что homeserver/UI может его увидеть и обработать как раньше.
|
|
||||||
|
|
||||||
- Ожидаемый результат:
|
|
||||||
- ESP32 UI читается на устройстве без кириллических строк.
|
|
||||||
- Подключение через trusted-device login стартует без server-side `INTERNAL_HANDLER_ERROR`, даже если настройки pairing ещё ни разу не сохранялись.
|
|
||||||
|
|
||||||
- Статус:
|
|
||||||
`pending`
|
|
||||||
@ -1,20 +0,0 @@
|
|||||||
# Browser wallet side panel
|
|
||||||
|
|
||||||
- Краткое описание:
|
|
||||||
browser extension `SHiNE Wallet` переведён с toolbar popup на штатный Chromium side panel.
|
|
||||||
|
|
||||||
- Что проверять:
|
|
||||||
1. Перезагрузить unpacked extension в Chromium-браузере.
|
|
||||||
2. Нажать на иконку `SHiNE Wallet` в toolbar.
|
|
||||||
3. Убедиться, что открывается side panel, а не всплывающий popup.
|
|
||||||
4. Проверить, что панель можно держать открытой при навигации по сайтам.
|
|
||||||
5. Проверить сценарии `Подключить`, `Отключить`, `Обновить устройства`, `Запросить кошелёк`.
|
|
||||||
6. Проверить, что сторона панели управляется браузером, а UI корректно выглядит и слева, и справа.
|
|
||||||
|
|
||||||
- Ожидаемый результат:
|
|
||||||
- расширение открывается в штатной боковой панели Chromium;
|
|
||||||
- UI работает так же, как раньше в popup;
|
|
||||||
- панель остаётся доступной как постоянная колонка браузера.
|
|
||||||
|
|
||||||
- Статус:
|
|
||||||
`pending`
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
# Wallet provider and ESP sign_transaction
|
|
||||||
|
|
||||||
- Краткое описание:
|
|
||||||
browser extension `SHiNE Wallet` теперь внедряет `window.solana` для сайтов и умеет выполнять `connect` и `signTransaction`; подпись транзакции уходит на ESP32 через wallet RPC `sign_transaction`, а подтверждение делается на устройстве.
|
|
||||||
|
|
||||||
- Что проверять:
|
|
||||||
1. Перезагрузить unpacked extension в Chromium.
|
|
||||||
2. Открыть сайт/тестовую страницу, которая вызывает `window.solana.connect()`.
|
|
||||||
3. Подтвердить подключение кошелька и убедиться, что сайт получает публичный ключ.
|
|
||||||
4. Открыть сайт/тестовую страницу, которая вызывает `window.solana.signTransaction(...)`.
|
|
||||||
5. Убедиться, что на ESP32 открывается экран `SIGN REQUEST` с комментарием.
|
|
||||||
6. Проверить оба варианта:
|
|
||||||
- `APPROVE` возвращает сайту подписанную транзакцию;
|
|
||||||
- `REJECT` возвращает отказ.
|
|
||||||
7. Проверить сценарии для `ClientKey`, `RootKey`, `Custom`.
|
|
||||||
|
|
||||||
- Ожидаемый результат:
|
|
||||||
- сайт может подключить кошелёк через provider расширения;
|
|
||||||
- транзакция подписывается только после подтверждения на ESP32;
|
|
||||||
- отказ на ESP32 корректно доходит до сайта.
|
|
||||||
|
|
||||||
- Статус:
|
|
||||||
`pending`
|
|
||||||
@ -1,18 +0,0 @@
|
|||||||
# Wallet Standard support
|
|
||||||
|
|
||||||
- Краткое описание:
|
|
||||||
расширение `SHiNE Wallet` теперь не только внедряет legacy `window.solana`, но и регистрирует себя как `Wallet Standard` wallet для Solana dapp.
|
|
||||||
|
|
||||||
- Что проверять:
|
|
||||||
1. Перезагрузить unpacked extension.
|
|
||||||
2. Открыть dapp, который использует Wallet Standard, например `app.realms.today` на `devnet`.
|
|
||||||
3. Открыть список кошельков и убедиться, что `SHiNE Wallet` появился отдельным вариантом.
|
|
||||||
4. Проверить `connect`.
|
|
||||||
5. Проверить подпись транзакции через сценарий dapp, который использует стандартный wallet interface.
|
|
||||||
|
|
||||||
- Ожидаемый результат:
|
|
||||||
- dapp видит `SHiNE Wallet` как standard wallet, а не только как legacy Phantom-style provider.
|
|
||||||
- connect и подпись работают через тот же ESP32 approval-flow.
|
|
||||||
|
|
||||||
- Статус:
|
|
||||||
`pending`
|
|
||||||
@ -1,26 +0,0 @@
|
|||||||
## Кратко
|
|
||||||
|
|
||||||
Исправлена ESP32-ветка обновления `user_pda` для добавления `homeserver`-сессии после миграции формата PDA на `RecoveryKeyBlock`.
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- В `shine_homeserver_main.ino` синхронизирован `create/update` payload с новым форматом `shine_users`.
|
|
||||||
- В сериализацию и парсинг PDA добавлен `RecoveryKeyBlock`.
|
|
||||||
- Для ветки `Add Homeserver` добавлены промежуточные checkpoint-записи в NVS, чтобы после crash или reset было видно, на каком шаге оборвалась операция.
|
|
||||||
- В `ESP32/AGENTS.md` добавлена памятка по чтению `last_error`.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- Зарегистрировать или использовать уже существующий аккаунт на ESP32.
|
|
||||||
- Дойти до состояния `homeserver not in PDA`.
|
|
||||||
- Нажать `Add Homeserver`.
|
|
||||||
- Если операция не успешна, считать `last_error` по USB serial и убедиться, что видна свежая запись именно по шагам `Homeserver PDA update ...`, а не старый diag.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- `Add Homeserver` добавляет `homeserver1` в `sessions` блока `SessionsBlock`.
|
|
||||||
- Если операция падает, в NVS сохраняется свежая диагностическая запись с текущим этапом, а не устаревший лог регистрации.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
`pending`
|
|
||||||
@ -1,39 +0,0 @@
|
|||||||
## Краткое описание
|
|
||||||
|
|
||||||
Доработан UX личного чата на мобильных устройствах:
|
|
||||||
- при открытой экранной клавиатуре нижний тулбар на 5 кнопок временно скрывается;
|
|
||||||
- после отправки собственного сообщения чат автоматически прокручивается вниз так, чтобы новое сообщение было видно сразу.
|
|
||||||
- при открытии уже существующего личного чата стартовая позиция выбирается по хвосту переписки:
|
|
||||||
- если есть непрочитанные сообщения, открытие происходит на линии `Новые сообщения`;
|
|
||||||
- если непрочитанных нет, чат открывается сразу в самом низу.
|
|
||||||
- на мобильной экранной клавиатуре `Enter` больше не отправляет сообщение, а создаёт новую строку;
|
|
||||||
- отправка выполняется только кнопкой `Отправить`;
|
|
||||||
- после отправки фокус остаётся в поле ввода, чтобы экранная клавиатура не закрывалась автоматически.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- открыть личный чат на телефоне;
|
|
||||||
- тапнуть в поле ввода и убедиться, что нижний тулбар скрывается после появления клавиатуры;
|
|
||||||
- закрыть клавиатуру и убедиться, что тулбар возвращается;
|
|
||||||
- отправить короткое сообщение, находясь не в самом низу переписки;
|
|
||||||
- убедиться, что после отправки экран прокручивается вниз и новое сообщение видно сразу;
|
|
||||||
- проверить то же поведение после прихода подтверждения отправки/перерисовки списка.
|
|
||||||
- открыть существующий чат с непрочитанными сообщениями и убедиться, что видна линия `Новые сообщения` и сообщения ниже неё;
|
|
||||||
- открыть существующий чат без непрочитанных сообщений и убедиться, что открыт конец переписки, а не начало.
|
|
||||||
- на телефоне нажать кнопку `Enter` на экранной клавиатуре и убедиться, что появляется новая строка, а сообщение не уходит;
|
|
||||||
- нажать кнопку отправки и убедиться, что сообщение отправилось, осталось видимым внизу и клавиатура не закрылась;
|
|
||||||
- отдельно проверить два сценария прокрутки после отправки:
|
|
||||||
- пользователь уже почти внизу и прокрутка идёт плавно;
|
|
||||||
- пользователь был заметно выше и чат догоняет новый хвост без лишних скачков.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- клавиатура не конфликтует по высоте с нижним тулбаром;
|
|
||||||
- при наборе доступно больше вертикального места;
|
|
||||||
- собственное только что отправленное сообщение сразу попадает в видимую область.
|
|
||||||
- при открытии чата пользователь сразу попадает в актуальную часть переписки.
|
|
||||||
- мобильный ввод не конфликтует с привычным поведением экранной клавиатуры.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
`pending`
|
|
||||||
@ -1,31 +0,0 @@
|
|||||||
## Краткое описание
|
|
||||||
|
|
||||||
Доработаны входящие уведомления для личных сообщений в сценарии, когда UI открыт, но страница скрыта на телефоне:
|
|
||||||
|
|
||||||
- для входящего DM при `document.visibilityState !== visible` UI пытается показать системное уведомление через `service worker`;
|
|
||||||
- добавлен `best effort` сигнал через `navigator.vibrate()`;
|
|
||||||
- добавлен короткий локальный звуковой сигнал через Web Audio, если аудио-контекст был ранее разблокирован пользовательским действием.
|
|
||||||
- для видимой активной страницы этот же сигнал теперь проигрывается на каждое новое входящее DM;
|
|
||||||
- для скрытой страницы звуковой сигнал сделан длиннее и заметнее.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- открыть SHiNE в Chrome/Android и один раз взаимодействовать со страницей;
|
|
||||||
- свернуть браузер или увести вкладку в фон, не закрывая её полностью;
|
|
||||||
- отправить DM с другого аккаунта;
|
|
||||||
- при открытой видимой странице тоже отправить DM и убедиться, что короткий сигнал воспроизводится без системного уведомления в шторке;
|
|
||||||
- проверить, что:
|
|
||||||
- сообщение пришло в шторку как системное уведомление;
|
|
||||||
- при поддержке устройства есть вибрация;
|
|
||||||
- на части устройств/браузеров может прозвучать локальный сигнал;
|
|
||||||
- отдельно проверить, что при открытой видимой странице не появилось лишних дублей системного уведомления.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- скрытая, но живая страница стала заметнее реагировать на входящий DM;
|
|
||||||
- уведомление в фоне не зависит только от `new Notification(...)` из страницы;
|
|
||||||
- если браузер разрешает локальный аудио-сигнал, пользователь слышит короткое оповещение.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
`pending`
|
|
||||||
@ -1,2 +1,2 @@
|
|||||||
client.version=1.2.275
|
client.version=1.2.276
|
||||||
server.version=1.2.255
|
server.version=1.2.256
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user