Hallo,

I'm currently playing with a minimalistic webpush setup, using notifies
without payload (using service worker code to fetch the notification
cause to display).

For Desktop Chomium+FF, everything seems to work as I expected so far.

But on android, when the fon is in low power mode during the the event, I
get an additional, android generated notification (about my "app" having
had an update in the background. I've never noticed such notifications
before).

My guess is: if this prob can be solved somehow (without specific user
interaction), then it could only be the service worker js code. But I'm
completely out of ideas about what I could try. It's not
ev.preventDefault(), I guess.

If you can ignore lot's of useless console.logs, hardcoded urls/test msgs
and outdated comments from tutorial imports, you could have a look at the
service worker code here:

https://jan.abnuto.de/pushtest/service-worker.js

Well, maybe using payload notfies could also sanitize things (maybe it's
a little more clear that visile user notification is intended in that
case). But payload data would only complicate things up a lot for me,
especially given that webpush might not yet have reached stable
specification state.

Gruss

Jan Bruns

To clarify the question and/or ease up a similar experiment for others...

A website/client registers web-push for my domain (by calling
pushManager.subscribe()), and sends the relevant subscription data to my
Notification source server.

On that server, to send a notification, I run the command

curl -v -X POST -H "Authorization: Bearer $jwt" -H "Crypto-Key:
p256ecdsa=$pubkey" -H "TTL:0" $link

where $pubkey is the same as the one that was passed to
pushManager.subscribe(), $link is the endpoint as returned by that call,
and $jwt is some infoblock signed using the private key corresponding to
$pubkey.

A Desktop FireFox behaves exactly as expected: If it is running, it
displays the Notification (no matter if the specific site is running).
Also if it isn't running, but is coming up within the specified TTL.

For Desktop Chromium, the behaviour is similar, but if the browser window
isn't maximized and doesn't show a tab with the site, it geneates an
addional Notification about backgound activity (that I don't intend to
generate!).

https://jan.abnuto.de/pushtest/Screenshot_desktop.png

With android chromium, the behaviour is similar to desktop chromium, but
a little relaxed in terms of "browser is running" as well as "tab showing
site", but the issue remains the same:

https://jan.abnuto.de/pushtest/Screenshot_20220626-031943_Chrome.jpg

How to prevent this additional Notification?

My guess is that it is shown because of the fetch (to give the user some
impression about tracking?). But I think it can also be closed (even
though I haven't yet functional code that doesn't break cross-brwoser
compatibility).

Does it maybe have a specific tag, so that it can be updated by the real
notification?

Maybe some non-standard info I could include into the $jwt? (it's
currently only: sub,aud,exp).

Gruss

Jan Bruns

PS: this service worker was used here:
https://jan.abnuto.de/pushtest/sw2.js

and, finally, here's a perl-script that can be used to generate the jwt,
to be called like:

$(perl perl.pl "https://host-from-endpoint" "mailto:admin@notify-sender"
seconds-jwt-valid)

https://jan.abnuto.de/pushtest/perl.pl

Jan Bruns:

> PS: this service worker was used here:
> https://jan.abnuto.de/pushtest/sw2.js

Tested this version which passes a new Promise to waitUntil(), that only
gets resolved after the notification is created. But the Problem remains
the same.

https://jan.abnuto.de/pushtest/sw3.js

What else could be tried?

Gruss

Jan Bruns

Jan Bruns:

> What else could be tried?

Well, after getting payload-data to work using

https://github.com/web-push-libs/ecec

I found out that even that way (without fetch() in the service worker
code) the duplicate notification problem persisted.

And the problem was:

For Desktop Chromium, it's not enough to simply call showNotification().
The push-event also needs to be waitUntil'ed for the promise returned by
showNotification().

Gruss

Jan Bruns

Hey guy. Would You want to get rich with me doing programming? If yes, call me !!!!!!!!!

✆☎☏📱📞 : 372 53900660

Jan Bruns kirjutas Neljapäev, 23. juuni 2022 kl 08:41:55 UTC+2:
> Hallo,
>
> I'm currently playing with a minimalistic webpush setup, using notifies
> without payload (using service worker code to fetch the notification
> cause to display).
>
> For Desktop Chomium+FF, everything seems to work as I expected so far.
>
> But on android, when the fon is in low power mode during the the event, I
> get an additional, android generated notification (about my "app" having
> had an update in the background. I've never noticed such notifications
> before).
>
> My guess is: if this prob can be solved somehow (without specific user
> interaction), then it could only be the service worker js code. But I'm
> completely out of ideas about what I could try. It's not
> ev.preventDefault(), I guess.
>
> If you can ignore lot's of useless console.logs, hardcoded urls/test msgs
> and outdated comments from tutorial imports, you could have a look at the
> service worker code here:
>
> https://jan.abnuto.de/pushtest/service-worker.js
>
> Well, maybe using payload notfies could also sanitize things (maybe it's
> a little more clear that visile user notification is intended in that
> case). But payload data would only complicate things up a lot for me,
> especially given that webpush might not yet have reached stable
> specification state.
>
> Gruss
>
> Jan Bruns

Hey... Want to talk? Call me.... My telephone number >>>>

(+372) 56330687

Jan Bruns kirjutas Neljapäev, 23. juuni 2022 kl 09:41:55 UTC+3:
> Hallo,
>
> I'm currently playing with a minimalistic webpush setup, using notifies
> without payload (using service worker code to fetch the notification
> cause to display).
>
> For Desktop Chomium+FF, everything seems to work as I expected so far.
>
> But on android, when the fon is in low power mode during the the event, I
> get an additional, android generated notification (about my "app" having
> had an update in the background. I've never noticed such notifications
> before).
>
> My guess is: if this prob can be solved somehow (without specific user
> interaction), then it could only be the service worker js code. But I'm
> completely out of ideas about what I could try. It's not
> ev.preventDefault(), I guess.
>
> If you can ignore lot's of useless console.logs, hardcoded urls/test msgs
> and outdated comments from tutorial imports, you could have a look at the
> service worker code here:
>
> https://jan.abnuto.de/pushtest/service-worker.js
>
> Well, maybe using payload notfies could also sanitize things (maybe it's
> a little more clear that visile user notification is intended in that
> case). But payload data would only complicate things up a lot for me,
> especially given that webpush might not yet have reached stable
> specification state.
>
> Gruss
>
> Jan Bruns