Make Badging API available through WorkerNavigator for service workers
Exposes setExperimentalAppBadge() and clearExperimentalAppBadge() on the navigator for service workers. When a service worker uses the badging API, the badge update affects all web apps within the scope of the service worker's registration. Future changes can expose the badging API to dedicated workers and shared workers. The WICG draft spec (https://wicg.github.io/badging/) states that dedicated workers and shared workers may set a badge when they are a service worker client. To expose badging on WorkerNavigator, this change updates the existing badging code under /blink/renderer/modules/badging/. The change adds a new IDL file, worker_navigator_badge.idl. The new IDL defines a partial WorkerNavigator interface to add the set and clear badging functions. The change updates the existing NavigatorBadge class to include the new WorkerNavigator IDL bindings, which are identical to the existing Navigator IDL bindings except they pass a WorkerNavigator& parameter instead of Navigator&. The change moves the core implementation from the existing Navigator IDL bindings into SetAppBadgeHelper() and ClearAppBadgeHelper(). These helpers enable both the Navigator IDL bindings and the WorkerNavigator IDL bindings to use the same implementation. The next part of the change registers a blink::mojom::BadgeService binder in the ServiceWorkerGlobalScope's browser interface binders. The ServiceWorkerGlobalScope needs this registration to connect the NavigatorBadge class to the badging::BadgeManager class in chrome/browser. Without this registration, the JavaScript badging APIs do not trigger any badge updates for service workers. For the Window, the binder registration occurs through ContentBrowserClient::RegisterBrowserInterfaceBindersForFrame(). Unfortunately, RegisterBrowserInterfaceBindersForServiceWorker() does not exist. Additionally, the Window binder registration provides the RenderFrameHost as context when creating a new mojo binding. The BadgeManager uses the RenderFrameHost as a binding context to find the URL to use when setting a badge. ServiceWorkerProviderHost is like RenderFrameHost, but for service workers. ServiceWorkerProviderHost can provide the service worker registration scope URL to use when setting a badge. Unfortunately, ServiceWorkerProviderHost is not publicly exposed to chrome/browser. This makes creating a RegisterBrowserInterfaceBindersForServiceWorker() problematic since the service worker cannot provide the same amount of context as the Window/Frame. Instead of using something like ContentBrowserClient::RegisterBrowserInterfaceBindersForFrame(), this change registers the badging binder in the content layer in browser_interface_binder.cc. Keeping the binder in the content layer allows it to use the ServiceWorkerProviderHost to get the context it needs and then pass that context to the BadgeManager in chrome/browser. The change adds the ContentBrowserClient::BindBadgeServiceReceiverFromServiceWorker(), which allows the content badging binder to pass the service worker's Render Process Host and its scope URL to the BadgeManager, which the BadgeManager uses as the binding context. The change updates the BadgeManager class to work with both service workers and documents. There are two differences between service worker and document badge updates: 1) A service worker badge update may affect multiple apps. A document badge update may affect up to one app. 2) Service workers and documents provide different mojo binding contexts. Service workers provide a RenderProcessHost and a scope URL. Documents provide a RenderFrameHost and a frame ID. To deal with these differences, this change updates the pre-existing BadgeManager::BindingContext struct to be an abstract interface base class. The class has one method to override: GetAppIdsForBadging(), which returns the list of AppIDs to update after a badge change. The change adds two derived classes FrameBindingContext and ServiceWorkerBindingContext. Each class handles the differences described above. For testing, this change updates WebAppBadgingBrowserTest to include service worker test cases. The change added new test data to chrome/test/data/web_app_badging/ to facilitate service worker testing. The new browser tests use the main frame to post a message to the service worker. Depending on the message content, the service worker responds by either calling setExperimentalAppBadge() or clearExperimentalAppBadge(). The change also generalizes WebAppBadgingBrowserTest to handle when a service worker badge change affects multiple apps. Before this change, WebAppBadgingBrowserTest expected exactly 1 badge update. After this change, the test can expect multiple badge changes with at most 1 badge change per app. The change also updates the badging origin trial API web_tests to include service workers. I attempted to update the existing badging web_tests to include workers, but since these tests run as file://, all workers failed to run due to null origin errors. I was also unsuccessful moving these tests to run as https:// since the https:// server did not have the required resources to mock mojo. Bug: 1036202 Change-Id: I66b2bf66b787965d6aa4ac35b663e522ffc4bd67 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2009376 Commit-Queue: Steve Becker <stevebe@microsoft.com> Reviewed-by:Matt Falkenhagen <falken@chromium.org> Reviewed-by:
Dominick Ng <dominickn@chromium.org> Reviewed-by:
Jeremy Roman <jbroman@chromium.org> Reviewed-by:
Jay Harris <harrisjay@chromium.org> Cr-Commit-Position: refs/heads/master@{#735705}
Showing
This diff is collapsed.
Please register or sign in to comment