iOS-Benachrichtigungen können die Push-Berechtigung verlieren, wenn der Benutzer gerade aktiv ist.

Fehler
1

iOS-Benachrichtigungen können die Berechtigung zum Pushen verlieren, wenn die Benachrichtigung unterdrückt wird. Der Code von Discourse ist so konfiguriert, dass Benachrichtigungen optional unterdrückt werden, und verliert dadurch bei dreimaligem Auftreten die Berechtigung zum Pushen.

Hier ist der Code für den Push-Benachrichtigungs-Dienstmitarbeiter.

Dieser Code enthält einen kritischen Fehler in Zeile 178. Dort prüft der Dienstmitarbeiter, ob der Benutzer aktiv ist (d. h. nicht im Leerlauf). In diesem Fall gibt das Push-Ereignis false zurück, ohne eine Benachrichtigung anzuzeigen.

(Es prüft auch payload.hide_when_active, aber es stellt sich heraus, dass hide_when_active immer true ist, und so gibt dieser Code immer false zurück, wenn der Benutzer aktiv ist.)

Apple verbietet stille Pushes und widerruft die Push-Berechtigung nach drei Ereignissen ohne Benachrichtigungen

Dies ist nach den Regeln von Apple für Push-Benachrichtigungen nicht akzeptabel.

https://webkit.org/blog/12945/meet-web-push/

Stromversorgung und Datenschutz

Sowohl das Open-Source-Projekt WebKit als auch Apple behandeln den Datenschutz als grundlegendes Menschenrecht. Wie bei anderen privilegierten Funktionen der Webplattform erfordert die Anforderung eines Push-Abonnements eine explizite Benutzergeste. Sie erfordert auch, dass Sie das Flag userVisibleOnly auf true setzen und dieses Versprechen einhalten, indem Sie immer eine Benachrichtigung als Reaktion auf eine Push-Nachricht anzeigen.

Die Web Push API ist keine Einladung für stille Hintergrundausführung, da dies sowohl das Vertrauen des Benutzers verletzen als auch die Akkulaufzeit des Benutzers beeinträchtigen würde.

Verstöße gegen das userVisibleOnly-Versprechen führen zum Widerruf des Push-Abonnements.

(Hervorhebung von mir)

Dies wird im WWDC-Video von Apple über Web Pushes ab 9:57 näher erläutert.

https://developer.apple.com/videos/play/wwdc2022/10098/?time=596

Beachten Sie, dass wir ausdrücklich angeben, dass wir versprechen, Pushes immer für den Benutzer sichtbar zu machen. Während der Standard für die JavaScript Push API optional stille Hintergrundausführung als Reaktion auf einen Push zulässt, unterstützen die meisten Browser dies nicht. Safari unterstützt dies nicht.

… und dann ab 13:35:

https://developer.apple.com/videos/play/wwdc2022/10098/?time=814

Wie ich bereits erwähnt habe, als ich Ihnen den Code zur Anforderung eines Push-Abonnements gezeigt habe, müssen Sie versprechen, dass Pushes für den Benutzer sichtbar sind. Die Verarbeitung eines Push-Ereignisses ist keine Einladung für Ihren JavaScript-Code, eine stille Hintergrundausführung zu erhalten. Dies würde sowohl das Vertrauen des Benutzers als auch die Akkulaufzeit des Benutzers verletzen. Bei der Verarbeitung eines Push-Ereignisses müssen Sie tatsächlich eine Benachrichtigung im Notification Center posten. Andere Browser haben Gegenmaßnahmen gegen die Verletzung des Versprechens, Pushes für den Benutzer sichtbar zu machen, und Safari ebenfalls. In der Beta-Version von macOS Ventura wird nach drei Push-Ereignissen, bei denen Sie es versäumen, eine Benachrichtigung rechtzeitig zu posten, das Push-Abonnement Ihrer Website widerrufen. Sie müssen den Berechtigungsworkflow erneut durchlaufen.

(Hervorhebung von mir)

Apple empfiehlt, Benachrichtigungen sofort anzuzeigen, nicht nach dem Schließen von Benachrichtigungen

Der empfohlene Code von Apple sieht ab 11:39 wie folgt aus:

https://developer.apple.com/videos/play/wwdc2022/10098/?time=699

self.addEventListener('push', (event) => {
    let pushMessageJSON = event.data.json();

    // Unser Server legt alles Notwendige zur Anzeige der Benachrichtigung
    // in unseren JSON-Daten ab.
    event.waitUntil(self.registration.showNotification(pushMessageJSON.title, {
        body: pushMessageJSON.body,
        tag: pushMessageJSON.tag,
        actions: [{
            action: pushMessageJSON.actionURL,
            title: pushMessageJSON.actionTitle,
        }]
    }));
}

Erinnern Sie sich, wie unser JavaScript beim Abonnieren von Push versprochen hat, dass diese immer für den Benutzer sichtbar sein werden? Das bedeutet, dass wir als Reaktion auf jeden Push immer eine plattformnative Benachrichtigung anzeigen müssen. Dies geschieht am besten so früh wie möglich in Ihrem Push-Ereignis-Handler.

Der Code von Discourse folgt nicht der empfohlenen Vorgehensweise. Der Code von Discourse schließt zuerst alle Benachrichtigungen und zeigt dann eine Benachrichtigung an.

Discourse sollte immer showNotification als Reaktion auf ein Push-Ereignis aufrufen, und zwar so schnell wie möglich.

8 „Gefällt mir“
2

@Falco / @featheredtoast Gedanken dazu?

Welche Auswirkungen hätte das Entfernen sowohl der Schließungs- als auch der Leerlaufprüfung?

Insgesamt bin ich mir bei dieser Leerlaufprüfung nicht sicher, sie scheint nur Verwirrung zu stiften.

Im schlimmsten Fall, wenn wir dies unter Android oder Desktop (nicht Safari) benötigen, können wir hier immer eine Bedingung hinzufügen, aber mein Gefühl ist, dass wir den Code hier einfach entfernen sollten.

Ausgezeichnetes Debugging @dfabulich :hugs:

3 „Gefällt mir“
4

Ich stelle fest, dass es in Ordnung ist, das Schließen durchzuführen, nehme ich an, solange es nach dem Aufruf von showNotification geschieht.

… aber ich sehe ehrlich gesagt keinen Sinn darin, Benachrichtigungen überhaupt zu schließen. Man könnte sie meiner Meinung nach genauso gut im Benachrichtigungsbereich ansammeln lassen.

Hinweis: Diese API sollte nicht einfach dazu verwendet werden, die Benachrichtigung nach einer festgelegten Verzögerung vom Bildschirm zu entfernen, da diese Methode die Benachrichtigung auch aus jedem Benachrichtigungsbereich entfernt und den Benutzer daran hindert, mit ihr zu interagieren, nachdem sie ursprünglich angezeigt wurde. Eine gültige Verwendung für diese API wäre das Entfernen einer Benachrichtigung, die nicht mehr relevant ist (z. B. wenn der Benutzer die Benachrichtigung in einer Messaging-App bereits auf der Webseite gelesen hat oder in einer Musik-App bereits der nächste Song abgespielt wird).

3 „Gefällt mir“
5

Nach allem, was ich an diesem Wochenende zu diesem Thema gelesen habe, können wir nicht einmal async/Promises im Push-Ereignis-Handler verwenden. Wir müssen es sofort anzeigen, sonst entzieht Apple uns die Benachrichtigungsrechte.

Das passt alles zu dem, was @dfabulich sagt.

Ich denke, wir sind hier zu „schlau“ für unser eigenes Wohl. Wir sollten tatsächlich alle Prüfungen entfernen und einfach die Benachrichtigung anzeigen.

6 „Gefällt mir“
6

Ich kann dir nicht genug dafür danken, @dfabulich, dass du das entdeckt hast!

3 „Gefällt mir“
7

OK, ich habe einen PR dafür.

@Falco / @featheredtoast sollen wir ihn mergen?

Wenn wir Push-Benachrichtigungen überspringen müssen, müssen wir das auf dem Server und nicht auf dem Client tun. Die Kollisionslogik war schon immer fragwürdig, Apps machen das eher nicht.

2 „Gefällt mir“
8

Oh ja, es ergibt viel mehr Sinn, Benachrichtigungen nur dann zu pushen, wenn sie angezeigt werden müssen. Sollte übermäßige Benachrichtigungen anderswo irgendwann bald unterdrücken, aber ich bin damit einverstanden, das hier zusammenzuführen :+1:

Re: Benachrichtigungen zusammenklappen, es ist schade zu verlieren, aber… idealerweise könnten wir ähnliches wie das automatische Ausblenden anderer Apps tun, wenn ein Benutzer seine Benachrichtigungen auf einem beliebigen angemeldeten Gerät durchgeht, aber das könnte etwas zusätzliche Vergoldung erfordern. Die Absicht ist dieselbe, niemals nur eine Flut veralteter Benachrichtigungen anzuhäufen. Auch hier ist es in Ordnung, aber wir müssen es später noch einmal überdenken, je nachdem, wie viel Schmerz es verursacht.

2 „Gefällt mir“