(In reply to Kris Maglione [:kmag] from comment #2)
We rely on ServiceWorkerCleanUp.jsm for this, which is the same implementation that the data sanitization UI uses.
ServiceWorkerCleanUp is a hack for cleaning up the Service Worker Registrations only. This will wipe out the ServiceWorker registrations and the hidden chrome-namespaced DOM Cache API storage that stores the offlines ServiceWorker script and dependencies, but is explicitly not for clearing content-space DOM Cache API storages. In the future when bug 1183245 is fixed, ServiceWorkerCleanUp will go away and automatically purge registrations when DOM Cache API storage for the origin is wiped (via QuotaManager).
browsingData API is unique in that it provides a granularity of removal options via browsingData.DataTypeSet that is not exposed by any Firefox UI. All Firefox UI (now) cleans up at the granularity of "offline apps" (or "cookies and site data"), which uses a combination of the hacky ServiceWorkerCleanUp and quotaManagerService.clearStoragesForPrincipal to clean up all QuotaManager clients (which includes IndexedDB, DOM Cache API, and imminently LocalStorage NextGen).
It does seem like the browsingData API is a bit of a foot-gun in terms of design; all data in an origin's storage bucket should be wiped at the same time to stick to the spec and avoid sites breaking or privacy-focused extensions accidentally leaving around super-cookie components. But if the API is going to be implemented as documented at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/DataTypeSet, then the code should be explicitly wiping the "cache" QuotaManager client as in comment 1 or gain some other type of property on DataTypeSet that maps to that underlying operation (and is documented to that effect).
A better option, in my mind, would be to map at least both "indexedDB" and "serviceWorkers" to "offlineApps" as understood by the Sanitizer logic. That way you can indeed use the same implementation that the data sanitization UI uses.
Moving back to WebExtensions but cc'ing the folks who maintain the logic in question in case they have a different opinion for this.