When a notification is to be shown, permission must first be checked: this is handled in the same way, invoking the NotificationPresenter in the renderer, jumping via synchronous IPC to the browser, checking the PrefLists and returning. The origin is then stored in the correct PrefList. A script may request permission on a given origin through a JS API which is routed through the NotificationPresenter interface, into the browser process via IPC, and results in an InfoBar offering "Allow" or "Deny". Chromium stores two PrefLists in the user's profile to accomplish this: OriginsAllowed and OriginsDenied. If a renderer process crashes, the notifications will persist in the browser process and on the screen, but events intended to reach that renderer process will be filtered out in the browser when normal process-lookup fails.ĭesktop notification permission is assigned on an origin basis.
If the browser subsequently calls with an event on that id it will be ignored. The NotificationPresenter interface supports this via a notificationObjectDestroyed() method which must be called from WebCore when a Notification object is destroyed.įor this reason, the renderer process's NotificationPresenter keeps a map of its notification-id values to Notification object pointers if a Notification pointer goes out of scope, the NotificationPresenter is called and removes that pointer from the map. However, as the javascript Notification object has gone out of scope, Chromium must not attempt to invoke events on it. If a page which is showing a desktop notification is closed, the toast should not be automatically removed from the screen. Since the renderer process chooses the id, the IPC involved can be asynchronous. Tracking is done by notification-id counters in each renderer process, and a map within the browser process which associates a toast on the screen with the corresponding renderer-process-id and notification-id. These events are detected in the browser process and flow back to the renderer instance which owns the notification object. Several events flow in the opposite direction: when a notification is displayed (it may not be immediate if the screen is cluttered), closed, or encounters an error, an event is fired which can be listened for by javascript. These calls flow via IPC from the renderer process to the browser process, where the toasts are actually created on the screen using a small HtmlView. In Chromium/WebKit, the API is provided to scripts in WebCore by injecting into WebKit (via the Chrome/ChromeClient objects) an implementation of a NotificationPresenter interface, which contains methods to show and cancel toasts, as well as to check and request permission to show toasts.
The contents of the toast can either be specified as iconUrl/title/text strings, or as a URL to a remote resource which contains the contents of the toast. The Desktop Notifications API allows script to request a small toast to appear on the desktop of the user.
0 kommentar(er)
