- From: Sebastian Noack <sebastian@adblockplus.org>
- Date: Wed, 5 Oct 2016 22:57:33 +0200
- To: Kris Maglione <kmaglione@mozilla.com>
- Cc: public-browserext@w3.org
Received on Wednesday, 5 October 2016 20:58:06 UTC
On Wed, Oct 5, 2016 at 9:45 PM, Kris Maglione <kmaglione@mozilla.com> wrote: > On Tue, Oct 04, 2016 at 04:05:08PM +0200, Sebastian Noack wrote: > >> As for compatibility with the existing Chrome extension API, I think that >> won't be an issue. We could just have methods take an optional callback >> and >> return also promise. IMO this would make more sense than a separate >> namespace or a new manifest option/version. >> > > That's the approach that Firefox currently takes for the `browser` > namespace, but we're likely to move to only supporting promises in that > namespace if that's what winds up in the spec. I think that for the sake of > simplicity and consistency, that's the approach that makes the most sense. Nice, and I totally agree. > One could write: >> >> browser.runtime.onMessage.addListener(function(message) >> { >> if (message == "get-foo") >> { >> return browser.storage.local.get("foo").then(items => items.foo); >> } >> }); >> > > As it happens, this is exactly how it currently works in Firefox :) Awesome, hopefully that makes it also into the spec. Sebastian
Received on Wednesday, 5 October 2016 20:58:06 UTC