This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When using a method that vends a promise, it's not clear to me what should happen when WebIDL says to throw a TypeError. The WebIDL spec should include something like: "If return type is Promise, and an exception has been thrown, instead return a rejected promise with that exception." See email thread: http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0772.html
Maybe it would make sense for IDL to define promises until they're integrated into JavaScript. That way it can avoid a dependency on DOM and I'll have to do less work.
That seems like a waste of time, tbh... why doesn't Promises just get housed in some TC-39 document (like with the internationalization stuff)? Then it can just be implemented whenever and doesn't need to be part of any ES version. The WebIDL can just reference it from there.
Well it does depend on HTML's event loop. JavaScript doesn't define such a thing anywhere.
(In reply to comment #3) > Well it does depend on HTML's event loop. JavaScript doesn't define such a > thing anywhere. That sounds like more reason to push it down the stack :) If the largest consumers of JS (Web/Node) both depend on the loop, this might encourage them to standardize it... which would be great as standardizing the event loop might provide an API to hook into it properly (instead of using setTimeout and matchMedia hacks).
(In reply to comment #4) > (In reply to comment #3) > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > thing anywhere. > > That sounds like more reason to push it down the stack :) If the largest > consumers of JS (Web/Node) both depend on the loop, this might encourage > them to standardize it... which would be great as standardizing the event > loop might provide an API to hook into it properly (instead of using > setTimeout and matchMedia hacks). TC39 is already planning to standardize the event loop in ES7, I believe. They don't need any further encouragement from us.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > > thing anywhere. > > > > That sounds like more reason to push it down the stack :) If the largest > > consumers of JS (Web/Node) both depend on the loop, this might encourage > > them to standardize it... which would be great as standardizing the event > > loop might provide an API to hook into it properly (instead of using > > setTimeout and matchMedia hacks). > > TC39 is already planning to standardize the event loop in ES7, I believe. > They don't need any further encouragement from us. <...insert Marcos + slowpoke pokemon meme here...> :) Anyway, sorry for dragging the bug off topic.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > > thing anywhere. > > > > That sounds like more reason to push it down the stack :) If the largest > > consumers of JS (Web/Node) both depend on the loop, this might encourage > > them to standardize it... which would be great as standardizing the event > > loop might provide an API to hook into it properly (instead of using > > setTimeout and matchMedia hacks). > > TC39 is already planning to standardize the event loop in ES7, I believe. > They don't need any further encouragement from us. The event loop will be specified as part of ES6.
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > > > thing anywhere. > > > > > > That sounds like more reason to push it down the stack :) If the largest > > > consumers of JS (Web/Node) both depend on the loop, this might encourage > > > them to standardize it... which would be great as standardizing the event > > > loop might provide an API to hook into it properly (instead of using > > > setTimeout and matchMedia hacks). > > > > TC39 is already planning to standardize the event loop in ES7, I believe. > > They don't need any further encouragement from us. Encouragement is always appreciated ;). > > > The event loop will be specified as part of ES6. ES6 is likely only to specify the minimal placeholder of an event loop as necessary to specify module loaders. The full event loop spec is indeed likely to be in ES7.
So, we need to fix WebIDL so that whenever an error is implicitly thrown (e.g. in the overload resolution algorithm, or maybe other places) by a Promise-returning function, it needs to automatically translate that to rejecting the returned promise. E.g. if I do Promise doSomethingAsync(DOMString arg) // non-optional var p = doSomethingAsync(); then p should be a Promise rejected with a TypeError, and a TypeError should not have been thrown. Should we use this bug for tracking that?
I was expecting that to happen as part of bug 21422. When promises are made available as something you can use in IDL.
Also, this bug reads remarkably like bug 21740.
(In reply to Anne from comment #10) > I was expecting that to happen as part of bug 21422. When promises are made > available as something you can use in IDL. I've indeed done that as part of bug 21422.