Веб-уведомления в iOS 16 в 2023 году

[dfabulich (Dan Fabulich)]

Это почти наверняка дело самого Discourse. Они просто не отправляют уведомления, если вы заходили на сайт определённое количество минут назад. Но так как у конечных пользователей нет возможности это увидеть, это делает уведомления ненадёжными. Однако я заверяю вас: я получил iOS-уведомления для обоих этих сообщений. Они могут работать, но только при условии, что вы никогда не будете им доверять.

[jtbayly]

Думаю, проблема наоборот. Если я недостаточно часто пользуюсь сайтом со своего телефона, уведомления перестают приходить.

[dfabulich (Dan Fabulich)]

Возможно, но мы все лишь гадаем. Главное, что нам нужно, — это чтобы Discourse обеспечивал адекватное ведение логов для конечных пользователей. Какие уведомления отправил Discourse? Какие уведомления Discourse решил не отправлять?

Когда PWA получает уведомление, оно может сохранить локальный лог этого события в IndexedDB на устройстве. Пользователи должны иметь возможность просматривать этот лог и сопоставлять его с логом сервера, чтобы увидеть, отправлял ли Discourse push-уведомление, но устройство его не получило.

В целом, я бы сказал: не предполагайте, что проблема в Apple, и особенно не полагайте, что простое ожидание iOS 18 поможет. Discourse должен предпринять действия здесь, иначе ничего не изменится к лучшему.

[sam (Sam Saffron)]

@Dan Fabulich

Какие уведомления отправил Discourse? Какие уведомления Discourse решил не отправлять?

Мне это кажется очень-очень подробным логированием:

app/services/post_alerter.rb

Добавить подробный лог здесь, вероятно, довольно просто:

app/jobs/regular/send_push_notification.rb

«Пропущено уведомление Сэма о “payload”, так как Сэм был онлайн».

Но если вы просто хотите отладить это, почему бы не установить SiteSetting.push_notification_time_window_mins в 0?

А затем следующий уровень логирования станет очень-очень подробным:

1. Пропущено уведомление, так как у пользователя включён режим «Не беспокоить».
2. Тайм-аут у провайдера push-уведомлений: discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
3. Истёк срок действия подписки.
4. Ошибка ответа.

Многие разные вещи могут пойти не так… хотя в любой момент времени вы, вероятно, можете использовать DE для проверки: посмотрите в таблице push_subscriptions на актуальные подписки на web push.

[dfabulich (Dan Fabulich)]

Позвольте мне начать с того, что, на мой взгляд, проблема заключается в том, что люди пишут здесь и на моём форуме: «Я считаю, что push-уведомления работают неправильно», а другие пользователи поддерживают их, говоря: «Да! У меня тоже! Уведомления должны быть сломаны/ненадёжны». Иногда они винят Apple, иногда — Discourse, но все сходятся во мнении, что push-уведомления в Discourse ненадёжны.

Я бы с радостью мог сам расследовать такие случаи, говоря: «Вы не получили уведомление в 12:31 на своём телефоне, и вот почему…», но я не верю, что это в настоящее время возможно.

@sam

Может пойти не так множество разных вещей…

Да, может пойти не так множество разных вещей, включая проблемы на стороне клиента, которые я не могу исследовать в DE.

• Получил ли Service Worker событие push?
• Вызвал ли Service Worker showNotification?
• Было ли предоставлено разрешение на showNotification, или showNotification не привело к никакому результату?
• Установлено ли на самом устройстве режим «Не беспокоить»?

@sam

хотя в любой момент времени вы, вероятно, можете использовать DE для проверки: посмотрите в таблице push_subscriptions на актуальные подписки для веб-пуша.

Мне бы очень хотелось иметь документацию для администраторов, объясняющую, как использовать DE для диагностики сбоя push-уведомлений, хотя бы в части проверки, дошло ли уведомление.

Но я также считаю, что было бы невероятно полезно вести журнал на стороне клиента, который пользователи могли бы отправлять мне, что позволило бы мне сопоставить его с журналом DE.

@sam

Но если вы просто хотите отладить это, почему бы не установить SiteSetting.push_notification_time_window_mins в 0?

Во-первых, как минимум половина людей, жалующихся на это, не являются администраторами своего форума. Вот почему нам нужно, чтобы Discourse реализовал это:

Let users configure their own push notification time window

push_notification_time_window is a site-wide setting; it’s 10 minutes by default. [image] Wait (n) minutes before sending push notification. Helps prevent push notifications from being sent to an active online user. I think this should be a user preference, instead of a site-wide setting. Some users might prefer 0-minute window or 1-minute window (especially when they’re testing push notifications); others might prefer a 10 minute window, or an even longer window.

Но, да, я подозреваю, что установка этого значения в 0 устранит 80% жалоб на «это не работает».

В целом, доверие пользователей к уведомлениям Discourse довольно низкое. Чем больше эта проблема будет поддаваться исследованию для администраторов (и даже для конечных пользователей), тем более надёжными будут казаться уведомления Discourse.

[sam (Sam Saffron)]

@Dan Fabulich

• Получил ли Service Worker событие push?
• Вызвал ли Service Worker showNotification?
• Был ли предоставлен доступ к showNotification, или же showNotification не выполнил никаких действий?

Я немного запутался в этом фрагменте: мы отправляем push-уведомление напрямую на URL с сервера…

[dfabulich (Dan Fabulich)]

@sam

Я немного запутался в этом фрагменте: мы отправляем запрос напрямую на URL с сервера…

Вот моя логика. Посмотрите, что говорят пользователи в этой теме.

@WorldIsMine

Мне приходится вручную отключать и включать уведомления, чтобы они работали. НО они работают всего несколько часов. Практически у всех моих участников, использующих функцию HomeScreen на iOS, наблюдается то же самое.

@jtbayly

Да, я сдался несколько месяцев назад.

Возможно, в 2024 году веб-уведомления на iOS 18 всё же заработают.

Эти сообщения, похоже, подразумевают, что проблема может быть на стороне Apple. Возможно, Discourse действительно отправляет запрос на URL, но по какой-то причине Apple не доставляет push-уведомление. Почему так может происходить?

1. Возможно, Apple возвращает код 4xx или 5xx для задачи push-уведомления, и Discourse должен повторить отправку.
2. Возможно, Apple получила сообщение, но не может (или не хочет?) доставить его на устройство.
3. Возможно, устройство получило сообщение, но Apple не вызывает событие push для сервисного воркера.
4. Возможно, сервисный воркер получил событие push, но из-за бага не вызвал showNotification (скорее всего, это не оно, иначе ошибка была бы слишком очевидной…?)
5. Возможно, сервисный воркер получил событие push и вызвал showNotification, но Apple отказалась показывать видимое уведомление. На самом деле существует множество причин для этого:
   • Устройство установлено в режим «Не беспокоить» (но в этом случае уведомление, думаю, должно eventually появиться в Центре уведомлений)
   • Разрешение было предоставлено ранее, но сейчас отозвано (PWA может обнаружить этот случай и записать его в лог!)
   • Пользователь мог настроить приложение со странными параметрами уведомлений, так что оно, например, отправляет уведомления только в Центр уведомлений, но не показывает баннер
   • … или Apple отказывается показывать сообщение по какой-то другой политике (возможно, они считают уведомление спамом?), и, возможно, в будущей версии iOS они станут более сговорчивыми

И это ещё не учитывая все причины, по которым сам Discourse может не отправить уведомление (режим «Не беспокоить», фильтры push-уведомлений, push_notification_time_window_mins).

Если всё, что мы можем сказать: «Ну, в 12:31 Discourse отправил уведомление с ID XXX в Apple, и Apple вернула статус 201 Created, но мы не знаем, что произошло дальше», — тогда у этих пользователей и администраторов не будет возможности провести дальнейшее расследование. Нам останется только винить Apple и отказаться от push-уведомлений. («Возможно, в 2024 году веб-уведомления на iOS 18 всё же заработают».)

Вместо этого нам нужно иметь возможность сказать: «Ваши логи на устройстве показывают, что в 12:33 сервисный воркер активировался по событию push для уведомления с ID XXX, вызвал showNotification, и мы видим через Notification API, что Apple подтверждает, что разрешение на showNotification для этого push-уведомления XXX было предоставлено».

(Я также считаю, что на странице https://meta.discourse.org/my/preferences/notifications должна быть кнопка «Отправить тестовое уведомление», которая позволяет запланировать уведомление на будущее, например, через N минут или N часов, чтобы пользователи могли протестировать случай «не работает через несколько часов».)

[WorldIsMine (DaveK)]

С моей стороны я не смог воспроизвести это на моём тестовом сайте. Уведомления там работают без проблем. Проблема возникает на моём рабочем сайте. Уведомления перестают работать через несколько часов каждый раз, когда я их включаю. Моя единственная теория заключается в том, что, возможно, проблема в объёме push-уведомлений? Мой рабочий сайт очень активен и имеет более 50 тысяч участников, поэтому отправляется много уведомлений на мой пользовательский аккаунт (и в целом).

[RGJ (Richard - Communiteq)]

Итак, я и @WorldIsMine провели небольшой эксперимент.

• Мы ждали, пока у него перестанут работать уведомления.
• Проверили, что его подписка на push-уведомления всё ещё есть в таблице push_subscriptions
• Я отправил push-уведомление из консоли Rails и записал все исключения в лог.

u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)

• Исключений не было.
• Он не получил уведомление.
• (Для перепроверки я смог отправить push-уведомление себе).

Получается, проблема на стороне Apple? Что это может быть?

[dfabulich (Dan Fabulich)]

У вас есть доступ к Mac для тестирования в Safari на macOS? Вы сможете настроить инструменты разработчика для отладки сервисного воркера там.

[RGJ (Richard - Communiteq)]

Насколько я понимаю, здесь не задействован сервисный воркер.

[dfabulich (Dan Fabulich)]

Нет, все веб-пуш-уведомления на iOS требуют наличия сервис-воркера. Sending web push notifications in web apps and browsers | Apple Developer Documentation

[RGJ (Richard - Communiteq)]

Ладно, это выше моего понимания. К сожалению, у меня нет опыта работы с этим на стороне клиента и нет под рукой Mac.

По крайней мере, мы исключили серверную часть.

[dfabulich (Dan Fabulich)]

Ага! Кажется, я нашел хотя бы одну ошибку с этим и создал отдельную тему.

iOS notifications can lose permission to push if the user is currently active

iOS notifications can lose permission to push if the notification is suppressed. Discourse’s code is configured to optionally suppress notifications, and will thereby lose permission to push when this happens three times. Here’s the code for the push-notification service worker. This code has a critical bug in it, at line 178. There, the service worker checks to see if the user is active (i.e. not idle). In that case, the push event returns false without showing a notification. (It also che…

[sam (Sam Saffron)]

Насколько я надеялся, что ваше исправление улучшит ситуацию, я всё ещё не уверен.

Meta была развернута с этим исправлением уже неделю. Я включил живые уведомления в PWA на своём iPhone. Сегодня они просто перестали работать.

Оно было создано 5 января.

Я попробую отладить это с помощью скрипта, чтобы понять, что вызывает сбой и как долго он длится, но многое указывает на то, что у Apple просто есть какой-то баг.

Чем больше я об этом думаю, тем больше убеждаюсь, что Discourse Hub теперь является решением для устройств Apple.

[jtbayly]

Спасибо, что отслеживаете это!

Вы переходили по каким-либо уведомлениям? Я спрашиваю, потому что интересно, не отключает ли Apple автоматически веб-уведомления, если вы получили определенное количество из них, ни на одно из которых не нажали.

[dfabulich (Dan Fabulich)]

Нам всё ещё нужны эти функции для анализа сбоев:

1. Инструкции по использованию Data Explorer для просмотра истории push-уведомлений.
2. Логи на устройстве, чтобы мы могли извлекать их и сопоставлять с серверными логами. Логи должны включать временные метки всех событий push, включая полный payload, а также статус Notification.permission.
3. Кнопка «Отправить тестовое уведомление», которая ставит уведомление в очередь на N минут/часов в будущем.

[sam (Sam Saffron)]

Обратите внимание: мои PWA-уведомления стабильно работали последние 3 недели на Meta

[nathank (Nathan Kershaw)]

Вот тревожное обновление, которое указывает на то, что нас ждут новые проблемы в этой сфере:

Apple broke web apps in iOS 17 beta and hasn't fixed them

[Nick_Chomey]

К вашему сведению, новость, о которой сообщил @nathank выше, полностью подтверждена Apple.

В откровенно злом духе соблюдения Закона ЕС о цифровых рынках (DMA), направленного на повышение открытости и конкуренции на цифровых платформах, Apple решила уничтожить PWA в ЕС с помощью предстоящего обновления Safari для iOS 17.4.

Это запретит установку PWA на главный экран, использование push-уведомлений, фоновую синхронизацию, а также нарушит работу офлайн-хранилища и другие функции. Более того, это окажет глобальное влияние, выходящее за пределы ЕС, поскольку компании будут гораздо менее склонны инвестировать в веб-приложения, и особенно в PWA, если пользователи iPhone в ЕС не смогут их использовать.

Я предполагаю, что это станет серьёзным препятствием для многих сообществ Discourse и для самого Discourse. Если это касается и вас, настоятельно рекомендую заполнить опрос от группы Open Web Advocacy. Они возглавляют борьбу с этими изменениями, информируя команду DMA обо всех последствиях этих и других политик для веб-разработки. Они срочно собирают отзывы и данные от компаний, которые пострадают от этих изменений, чтобы предоставить DMA более полную информацию для противодействия.

Пожалуйста, посетите эту страницу, чтобы узнать больше, заполните их опрос о том, как это влияет на ваш бизнес, и распространите информацию! Было бы особенно замечательно, если бы Discourse предупредил своих пользователей о предстоящих изменениях, чтобы каждый мог связаться с OWA и объяснить, как это влияет на их бизнес и сообщества.

Immediate Action Needed! - Open Web Advocacy