Bug 243659 – [GTK][WPE] Expose notifications without a page in public API

• Status: NEW
• Component: WebKitGTK

[Carlos Garcia Campos]

Current notifications API is a signal emitted by WebKitWebView, but service worker notifications don't have a page associated. They don't even belong to a web process pool, there's a global notification manager for service workers. Some options that came to my mind:

 1) Deprecate current web view signal and add a global WebKitNotificationManager that emits the signal and provides the web view as an optional parameter (it could also be a property of the notification, but we would need to keep a ref of the web view in every notification).
 2) Keep current API and add a global notification manager only for service worker notifications.

I think it's probably better to add the global singleton to handle all notifications with the web view passed as a parameter. Note that Notification.requestPermission is always handled by the web process pool notification manager, so current api in web context is not affected and should still work.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #0) 
> I think it's probably better to add the global singleton to handle all
> notifications with the web view passed as a parameter.

I agree. Of course, this would not break the existing WebKitWebView API that you would deprecated.

The downside is this would be our first global API that is not associated with a WebKitWebContext, which breaks the illusion that it's a true library context object and you can have separate instances of WebKit running if you have multiple WebKitWebContext objects. That doesn't seem to be avoidable, but maybe we could design it so that it looks like it's a property of the WebKitWebContext even though it's not really? We could have webkit_web_context_get_notification_manager() and it would just return the same WebKitNotificationManager regardless of which WebKitWebContext you are using, but maybe 10 years from now if internals change it would be possible to revisit that without needing another API break. On the other hand, maybe that's overengineering.

[Patrick Griffis]

(In reply to Michael Catanzaro from comment #1)
> The downside is this would be our first global API that is not associated
> with a WebKitWebContext, which breaks the illusion that it's a true library
> context object and you can have separate instances of WebKit running if you
> have multiple WebKitWebContext objects. That doesn't seem to be avoidable,
> but maybe we could design it so that it looks like it's a property of the
> WebKitWebContext even though it's not really? We could have
> webkit_web_context_get_notification_manager() and it would just return the
> same WebKitNotificationManager regardless of which WebKitWebContext you are
> using, but maybe 10 years from now if internals change it would be possible
> to revisit that without needing another API break. On the other hand, maybe
> that's overengineering.

My thoughts are probably the closer the API is to WebKit internals the better for everybody. Less WebKitGTK complication, more robust to WebKit changes, etc.