[Webkit-unassigned] [Bug 163366] New: [GTK] No way for applications to set notification permissions without waiting for permission request

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=163366

            Bug ID: 163366
           Summary: [GTK] No way for applications to set notification
                    permissions without waiting for permission request
    Classification: Unclassified
           Product: WebKit
           Version: Other
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at igalia.com
                CC: aperez at igalia.com, bugs-noreply at webkitgtk.org,
                    gns at gnome.org

Websites can check the Notification.permission DOM property [1] to check if they have permission to show notifications without triggering an intrusive permission request (that's done via Notification.requestPermission()). But the WebKitGTK+ API has no way to affirmatively indicate notifications are allowed. The only way is via the permission request API, which is too late. It's a problem for Epiphany. For example, open the Riot Matrix client in a web app; you will immediately see an info bar informing the user that Riot does not have permission to send desktop notifications, even though Epiphany automatically grants notification permission in web app mode when requested.

The problem is in WebKitNotificationProvider.cpp, where we need to implement notificationPermissionsCallback of WKNotificationProviderV0. The WKDictionaryRef returned by that callback should be set by some new API function. Simple proposal:

void webkit_web_context_set_notification_permissions (WebKitWebContext *context, GHashTable *permissions);

where the hash table is a map of strings to bools.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161012/988554ac/attachment-0001.html>