1618632 - Not receiving more notification permission requests after blocking/granting for some specific site

Status: RESOLVED MOVED

(GeckoView :: General, defect, P1)

Description

[Arturo Mejia [:amejia]]

If you go to https://www.pushengage.com/demo and click the Send Demo Notification button it will call onContentPermissionRequest as a PERMISSION_DESKTOP_NOTIFICATION was created, but after granting or rejecting the first time we are not getting more calls to onContentPermissionRequest callback even if the session is refreshed, more information in the Fenix issue

Comment 1

[Eugen Sawin [:esawin]]

The STR from the Fenix issue reads as follows:

1. Go to https://pushalert.co/demo, https://www.pushengage.com/demo
2. Tap to send a demo notification, tap Block notifications on the permission request dialog.
3. Tap the lock icon and tap Allow notifications. Try to send the push notification.
4. Go to Settings>Site permissions and Allow notifications for these websites. Try to send the push notification.
5. Lastly, clear permissions for these websites. Try to send the push notification.
6. Restart the browser after allowing notifications. Try to send the push notification.

On reproducing of the issue, I don't see any calls to GV StorageController to clear site settings or permissions. How does Fenix/A-C clear the GV permissions (steps 3-5)?
For comparison, Delete browsing data does call into StorageController to remove the existing permissions for the runtime and that results in the expected behavior.

Comment 2

[Arturo Mejia [:amejia]]

For site permissions, AC is storing a list of all permissions and every time GeckoView notifies us about a new permissions request onContentPermissionRequest, we reject or grant the request depending on what is on the storage or user's preferences

Comment 3

[Eugen Sawin [:esawin]]

(In reply to Arturo Mejia from comment #2)

For site permissions, AC is storing a list of all permissions and every time GeckoView notifies us about a new permissions request onContentPermissionRequest, we reject or grant the request depending on what is on the storage or user's preferences

The issue here seems to be that once Fenix has handled a content permission request, GV may not trigger any requests on the same permission-site pair for the active runtime.

Currently, you have to explicitly remove the permission via StorageController for the active runtime, like you do it in the Delete browsing data case.

Comment 4

[Arturo Mejia [:amejia]]

I'm bit confused, I thought GeckoView wasn't saving any state related to site permissions, and it was the responsibility of the consumer to do that. As a result, the consumer will always receive calls to onContentPermissionRequest and determine if it should be rejected or granted.

If I go to https://permission.site/ and tap the location button and grant or deny it the prompt, I always get calls on onContentPermissionRequest as soon as the page is refreshed and I tap the button again. What is the difference with https://pushalert.co/demo, https://www.pushengage.com/demo?

Comment 5

[Eugen Sawin [:esawin]]

(In reply to Arturo Mejia from comment #4)

I'm bit confused, I thought GeckoView wasn't saving any state related to site permissions, and it was the responsibility of the consumer to do that. As a result, the consumer will always receive calls to onContentPermissionRequest and determine if it should be rejected or granted.

If I go to https://permission.site/ and tap the location button and grant or deny it the prompt, I always get calls on onContentPermissionRequest as soon as the page is refreshed and I tap the button again. What is the difference with https://pushalert.co/demo, https://www.pushengage.com/demo?

This behavior is definitely confusing because it not only depends on the type of the permission but also on the way the permission is requested by the site.

You're seeing different behavior for https://permission.site (even for the Notification permission) and the other two sites because the former doesn't register service workers, while the latter sites do.
Both, pushalert and pushengage register service workers and rely on the cached permission (Navigation.permission) rather the requesting the permission each time (Navigation.requestPermission).

Currently, in order to clear the runtime-persistent permissions, you need to clear them using StorageController, otherwise you will not get prompted for the permission again (since the site never calls Navigation.requestPermission).

I'm proposing to implement this behavior in Fenix/A-C, since there might not be a reliable short-term solution for this within GeckoView.

Comment 6

[Arturo Mejia [:amejia]]

(In reply to Eugen Sawin [:esawin] from comment #5)

(In reply to Arturo Mejia from comment #4)

I'm bit confused, I thought GeckoView wasn't saving any state related to site permissions, and it was the responsibility of the consumer to do that. As a result, the consumer will always receive calls to onContentPermissionRequest and determine if it should be rejected or granted.

If I go to https://permission.site/ and tap the location button and grant or deny it the prompt, I always get calls on onContentPermissionRequest as soon as the page is refreshed and I tap the button again. What is the difference with https://pushalert.co/demo, https://www.pushengage.com/demo?

This behavior is definitely confusing because it not only depends on the type of the permission but also on the way the permission is requested by the site.

You're seeing different behavior for https://permission.site (even for the Notification permission) and the other two sites because the former doesn't register service workers, while the latter sites do.
Both, pushalert and pushengage register service workers and rely on the cached permission (Navigation.permission) rather the requesting the permission each time (Navigation.requestPermission).

Currently, in order to clear the runtime-persistent permissions, you need to clear them using StorageController, otherwise you will not get prompted for the permission again (since the site never calls Navigation.requestPermission).

I'm proposing to implement this behavior in Fenix/A-C, since there might not be a reliable short-term solution for this within GeckoView.

Got it!

I'm not sure how cheap or expensive it is to call runtime.storageController.clearDataFromHost(host, StorageController.ClearFlags.PERMISSIONS), to avoid any performance overhead, is it a way for us to detect when exactly should we clear?

Comment 7

[Eugen Sawin [:esawin]]

(In reply to Arturo Mejia from comment #6)

I'm not sure how cheap or expensive it is to call runtime.storageController.clearDataFromHost(host, StorageController.ClearFlags.PERMISSIONS), to avoid any performance overhead, is it a way for us to detect when exactly should we clear?

It should be a relatively cheap operation. Also, the GV API is async, so you don't have to block UI for it.
I think the workaround is only required for PERMISSION_DESKTOP_NOTIFICATION.

Comment 8

[Eugen Sawin [:esawin]]

Fixed in A-C.

Comment 9

[Jasen Hudson]

Thanks for posting the information it was really helpful to resolve the same occurring bug.