On Mon, Nov 25, 2013 at 3:51 PM, wrote:
> Based on bholley's comments on bug 939636, chrome code will need to do
>
> Cu.importGlobalProperties(["Promise"]);
>
> to use DOM Promises.
>
Well, more specifically, chrome code running in non-Window scopes (so
JS-implemented Components, JSMs, privilege
On Tuesday, November 19, 2013 10:48:24 AM UTC-8, Brandon Benvie wrote:>
> There's two mostly orthogonal concerns here. The first is the sync/async
>
> issue:
>
>
>
> console.log(1);
>
> promise.resolve().then(() => {
>
>console.log(2);
>
> });
>
> console.log(3
On Monday, November 25, 2013 12:25:00 PM UTC-8, jsan...@gmail.com wrote:
> Is there a consensus on removing Promise.jsm completely? As Benvie said, the
> majority of work will be migrating over from `sdk/core/promise.js` (sync) to
> the async Promise.jsm, which share APIs. Converting Promise.jsm
Is there a consensus on removing Promise.jsm completely? As Benvie said, the
majority of work will be migrating over from `sdk/core/promise.js` (sync) to
the async Promise.jsm, which share APIs. Converting Promise.jsm to consume DOM
Promises is pretty straight forward, and would still give us ou
On Thu, Nov 21, 2013 at 9:00 PM, Paolo Amadini wrote:
> Though it may seem counter-intuitive, the non-native Promise.jsm has
> grown better error reporting and debuggability, and maybe even better
> performance (depending on whether DOM Promises are optimized for not
> returning to the outer OS ev
On 21/11/2013 13:41, Brandon Benvie wrote:
> On 11/20/2013 9:27 PM, Philip Chee wrote:
>> This is singularly unhelpful. Can we have better error stacks?
>
> This is actually a *really* useful error stack for people who know about
> the library in question throwing the error, and bugs have been f
On 11/21/13 2:00 PM, Paolo Amadini wrote:
I hope to see a comparable or even better level of debuggability in the
native Promise implementation soon!
Are there bugs filed on what's missing here? It should be pretty simple
to implement all sorts of things here as needed, but we need a clear
On 19/11/2013 1.38, Nikhil Marathe wrote:
> DOM Promise has been in the tree for a while
> We currently have two JS promise implementations in our codebase:
> toolkit/modules/Promise.jsm
Though it may seem counter-intuitive, the non-native Promise.jsm has
grown better error reporting and debuggabi
On 11/20/2013 9:27 PM, Philip Chee wrote:
Currently, I'm getting this in the Error Console a few seconds after
startup:
Thu Nov 21 2013 13:23:23
Error: A promise chain failed to handle a rejection.
Date: Thu Nov 21 2013 13:23:13 GMT+0800 (Malay Peninsula Standard Time)
Full Message: [object St
On 20/11/2013 01:30, Boris Zbarsky wrote:
> On 11/19/13 12:26 PM, Anne van Kesteren wrote:
>> On Tue, Nov 19, 2013 at 5:17 PM, Boris Zbarsky wrote:
>>> It's been the case since late August, though the behavior is a bit
>>> different: only thrown Errors or rejections with an Error are logged, not
>
On Wed, Nov 20, 2013 at 4:04 PM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> On 11/20/13 1:09 PM, Till Schneidereit wrote:
> > How about logging them with console.info? That seems the right logging
> > level to me, and it's easy to turn off if it gets in the way.
>
> Well, the problem
On 11/20/13 1:09 PM, Till Schneidereit wrote:
> How about logging them with console.info? That seems the right logging
> level to me, and it's easy to turn off if it gets in the way.
Well, the problem is that of logging uncaught rejections. You can log
them only if you catch them.
Cheers,
David
On Wed, Nov 20, 2013 at 12:36 PM, Boris Zbarsky wrote:
> I guess no less useful than the current error console reporting for "throw
> 42" in a function which is already pretty useless.
When I said we report "throw 42" I meant in a function context. Hence
the analogy I made.
--
http://annev
On 11/20/13 7:34 AM, Boris Zbarsky wrote:
We could certainly try to report everything. It would be pretty
bare-bones, since for things that are not Error we don't have line/file
information as to where they originated, so all we can report is that
some promise somewhere was rejected with the val
On 11/20/13 6:51 AM, Anne van Kesteren wrote:
On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote:
We could report all rejections, but I'm a bit leery of adding so much noise
that people start ignoring the report altogether; a common problem in the
past.
Given that we report "throw 42"
We
On Wed, Nov 20, 2013 at 12:51 PM, Anne van Kesteren wrote:
> On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote:
> > We could report all rejections, but I'm a bit leery of adding so much
> noise
> > that people start ignoring the report altogether; a common problem in the
> > past.
>
> Given th
On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky wrote:
> We could report all rejections, but I'm a bit leery of adding so much noise
> that people start ignoring the report altogether; a common problem in the
> past.
Given that we report "throw 42" we should also report these I think. A
promise is
On 11/19/2013 10:12 AM, nsm.nik...@gmail.com wrote:
Is there are reason devtools cannot switch to DOM Promises directly rather than
go through making Promise.jsm a wrapper around DOM Promise? The current promise
implementations which allow resolving later are leading to very un-idiomatic
promi
On Monday, November 18, 2013 5:36:48 PM UTC-8, Brandon Benvie wrote:
> On 11/18/2013 4:54 PM, Dave Townsend wrote:
>
> > There are add-ons using the existing promises implementations. Is there any
>
> > reason not to make those wrappers around the DOM promises to avoid
>
> > potential bustage?
>
On Monday, November 18, 2013 4:54:31 PM UTC-8, Dave Townsend wrote:
> There are add-ons using the existing promises implementations. Is there any
>
> reason not to make those wrappers around the DOM promises to avoid
>
> potential bustage?
>
>
>
> At least the add-on SDK promises library provi
On 11/19/13 12:26 PM, Anne van Kesteren wrote:
On Tue, Nov 19, 2013 at 5:17 PM, Boris Zbarsky wrote:
It's been the case since late August, though the behavior is a bit
different: only thrown Errors or rejections with an Error are logged, not
arbitrary rejections.
Why are we doing it only for
On Tue, Nov 19, 2013 at 5:17 PM, Boris Zbarsky wrote:
> It's been the case since late August, though the behavior is a bit
> different: only thrown Errors or rejections with an Error are logged, not
> arbitrary rejections.
Why are we doing it only for Error objects?
--
http://annevankesteren.n
On 11/19/13 12:05 PM, David Rajchenbach-Teller wrote:
Generally, I believe that it's a good idea, if DOM Promises have the
equivalent of:
https://dutherenverseauborddelatable.wordpress.com/2013/10/14/recent-changes-to-promise-jsm-and-task-jsm/
Is this the case already?
It's been the case sinc
Generally, I believe that it's a good idea, if DOM Promises have the
equivalent of:
https://dutherenverseauborddelatable.wordpress.com/2013/10/14/recent-changes-to-promise-jsm-and-task-jsm/
Is this the case already?
Cheers,
David
On 11/19/13 1:38 AM, Nikhil Marathe wrote:
> (Cross posted to fi
On 11/18/2013 4:54 PM, Dave Townsend wrote:
There are add-ons using the existing promises implementations. Is there any
reason not to make those wrappers around the DOM promises to avoid
potential bustage?
At least the add-on SDK promises library provides functionality beyond that
that appears t
> My intention is:
> 1) Enable Promises for all chrome code.
Is this plan that enable to use DOM Promise in all chrome code?
I think, Promise will be introduced in ECMA6, then we will be able to
use Promise as one of the standard library of ECMAScript in js code
module environment, when Spidermon
There are add-ons using the existing promises implementations. Is there any
reason not to make those wrappers around the DOM promises to avoid
potential bustage?
At least the add-on SDK promises library provides functionality beyond that
that appears to be in the DOM promises (custom prototypes fo
(Cross posted to firefox-dev, please reply on dev.platform)
DOM Promise has been in the tree for a while, and is enabled for
ChromeWorkers and certified apps. With a couple of patches, it will achieve
conformance with the AP2 spec [1], which is what TC39 has accepted as the
bare minimum for Promis
28 matches
Mail list logo
