- 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