@thodan -- Thank You for the report.
Navigated to the html file provided and observed error messages in the Console.
Is this the actual behavior you are seeing.
Could you please provide any screen cast of the issue which would help us in better understanding and triaging the issue further.

Sorry, I uploaded the wrong file -- please disregard that file and use this newly attached file instead (vanilla_promises2.html).

The issue in a nutshell: when there is a "success" condition for the Promises.all, the callback returns an array (see the console output). Now try changing both image URLs from .jpg to .aaa or whatever to force an error condition. The expected out is that the error callback also returns an array, but instead it returns a string pass from the first rejected call.

Deleted: vanilla_promises2.html 1.3 KB

vanilla_promises2.html 1.3 KB View Download

Is this working as intended?

If this is by design, then please change this to an enhancement request. To have a consistent, predictable behavior, both success and error conditions should return either a string or an array (preferred), not one of each.

The semantics of Promise.all make sense to me personally--if any fails, then Promise.all fails, and it doesn't wait for everything else to complete before it completes. It's possible to build basically any Promise combinator you want out of .then(). Promise.all has been shipped in several browsers, so I would have significant reservations from a web-compatibility perspective about changinging it. If you want different Promise functionality shipped by V8, the best thing to do would be to pursue it through the TC39 process. Promise.prototype.finally is in progress this way.

@littledan Thanks for the reply; I see your point about potentially breaking existing apps. My use case was loading 10 images concurrently and giving the end user a report of all images that failed to load. I thought if I wanted to short-circuit, then I would use chaining. Since Promise.all also only reports the first error, then in this regards it is no different than chaining.

thdoan, you can see the current specification at https://tc39.github.io/ecma262/#sec-promise.all . The logic is explicitly short-circuiting. Feel free to propose a new library feature to meet your different use case.