Re: Intent to ship: Promise.allSettled

On 11/1/2019 2:42 PM, Jan-Ivar Bruaroey wrote: My original point was that the semantics of Promise.allSettled, which are "keep waiting for the lot even if some async operations fail", did not deserve its own standard name in the JS language, because of A) how rarely this is actually what you w

Re: Intent to ship: Promise.allSettled

On 10/31/2019 1:57 PM, Jan-Ivar Bruaroey wrote: The context here is the same as Promise.allSettled: we explicitly *do* want to ignore errors, right? In general, in mozilla-central we want to at least log those errors, at which point they are already caught, and using "Promise.all" is then equiv

Re: Consider avoiding allSettled in tests

On 10/31/2019 1:02 PM, Jason Orendorff wrote: On Thu, Oct 31, 2019 at 4:10 AM Paolo Amadini wrote: // INCORRECT //await Promise.allSettled([promise1, promise2]); The last example silently loses any rejection state. Ignoring the awaited value here is like using `catch {}` to

Re: Intent to ship: Promise.allSettled

On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote:     Promise.all(promises.map(p => p.catch(e => e))) https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549 By the way, this "catch(e => e)" call may make sense as an example in the

Consider avoiding allSettled in tests (was: Re: Intent to ship: Promise.allSettled)

On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote: This always seemed trivial to me to do with:     Promise.all(promises.map(p => p.catch(e => e))) As Boris pointed out, this does not have proper exception handling. If exceptions should be ignored, it may be good to call "console.error". In case

Re: New and improved "about:config" for Firefox Desktop

On 2/2/2019 10:02 PM, Philipp Kewisch wrote: On 1/24/19 11:25 PM, Paolo Amadini wrote: I'm not expecting any major changes to the new about:config that would require communication, as long as a the boundary between toolkit and browser is kept. On this specifically, the boundary be

Re: New and improved "about:config" for Firefox Desktop

On 1/26/2019 10:09 AM, khagar...@gmail.com wrote: Does it take into account that the sorting is preserved between about:config calls? No, but 0.4% is still very low. We could imagine that a lot of people keep the table sorted by type at all times, or that only a few people do or even know that

Re: New and improved "about:config" for Firefox Desktop

enough for your use case. I'd expect most reports to come in after we've switched the default. Cheers, Paolo On 1/25/2019 10:52 PM, Mike Hommey wrote: On Fri, Jan 25, 2019 at 10:36:16PM +, Paolo Amadini wrote: On 1/25/2019 10:39 AM, Axel Hecht wrote: Is there a tracking bug for follo

Re: New and improved "about:config" for Firefox Desktop

On 1/25/2019 10:39 AM, Axel Hecht wrote: Is there a tracking bug for follow-ups? Please file bugs blocking bug 1493439, I'll triage them as necessary. filter [...] by modified This is bug 1502867, it is something we've considered but I'm a bit conflicted as it's only really used on 0.4% of

Re: New and improved "about:config" for Firefox Desktop

On 1/24/2019 9:57 PM, Philipp Kewisch wrote: was there a specific reason to put the code in chrome://browser/ ? It seems to me that this is a feature that is common for all toolkit apps, so if you put it in chrome://toolkit/ then Thunderbird can just make use of it without any major migration nee

New and improved "about:config" for Firefox Desktop

Last year a group of students, Luke, Matthias, and Vincent, designed and implemented a new version of "about:config" in order to improve the ergonomics and align the look and feel with other in-content Firefox pages. They did an amazing job, working with design input from Amy Lee and with myself d

Re: Switching to async/await from Task.jsm/yield

On 3/17/2017 5:19 PM, Dave Townsend wrote: One issue I have just spotted is that Task.jsm uses a JavaScript implementation of promises under the hood while async/await obviously uses our native implementation in the JS engine. You're inadvertently losing test coverage if you convert everything

Scheduling of async functions

Take the following code example: someCondition = false; async function onClick(event) { if (someCondition) { await Promise.resolve(); // Or any other async function. } event.stopPropagation(); } let called = false; onClick({ stopPropagation: () => called = true })

Re: Converting assertions into release assertions

On 9/23/2016 1:49 PM, Gijs Kruitbosch wrote: Then this enables me to answer Ehsan's question. These are the builds I've recently tried using (e.g. when debugging intermittents in VMs because then I don't need to set up too much of a build env) and they're still very slow. Some time ago I ventil

Re: Just Autoland It

On 1/22/2016 2:00 PM, Mark Hammond wrote: (Hopefully) related - what exactly is the "checkin?" flag for? As far as I understand, it's used together with the "checkin-needed" keyword when there is ambiguity about which of the attachments in the bug should be landed by the sheriffs or the reviewe

Feel free to use Iterator() in privileged JS (was: Re: Help with removing __iterator__ from JS)

On 7/23/2015 4:16 PM, Boris Zbarsky wrote: I might be missing something, but why is __iterator__ and the nonstandard iteration protocol needed for this? It's not. I don't think anyone on the SpiderMonkey end particularly cares whether Iterator or some replacement is used. Thanks a lot for t

Re: Help with removing __iterator__ from JS

On 7/22/2015 1:56 PM, David Bruant wrote: The ES6 iterator protocol is what you're looking for. See: Alongside with the computed property syntax, you should be able to achieve what you want. Something along the lines of: Well, I was thinking more of something built-in, other than Iterator, to a

Re: Help with removing __iterator__ from JS

On 7/21/2015 12:07 PM, Tom Schuster wrote: Aside: Please also try avoid using Iterator(). What would be the alternative to Iterator() when I need to iterate and easily assign both keys and values of an object to local variables? See for example

Re: Is anyone still using JS strict warnings?

On 12/26/2014 5:59 PM, Jeff Walden wrote: > On 12/22/2014 08:08 AM, Paolo Amadini wrote: >> Maybe we could make available >> an opt-in code linting solution - and these typos would become errors, >> not warnings, > > Introducing our own proprietary version of JS with

Re: nsIDownloadManager slated for removal

On 12/22/2014 5:01 PM, Ehsan Akhgari wrote: > There are numerous add-ons that depend on nsIDownloadManager, > unfortunately: Do we have a plan for them? From the add-ons point of view, the mere removal of nsIDownloadManager from mozilla-central is a bookkeeping operation. With regard to add-ons

nsIDownloadManager slated for removal

Now that Firefox for Android migrated to the new Downloads.jsm API, we're going to remove the legacy nsIDownloadManager implementation from the mozilla-central repository. This will happen gradually, probably over the next month or two. At the time of the Downloads.jsm implementation, a migration

Re: Is anyone still using JS strict warnings?

On 12/19/2014 8:19 PM, Jason Orendorff wrote: > Maybe it's time to retire this feature. I'd be fine with this. One of the confusing aspects of these warnings is that they are enabled or disabled by default based on whether the build is a debug build ("javascript.options.strict" vs "javascript.opt

Re: Upcoming changes to autocomplete code affecting Thunderbird

On 8/30/2014 2:18 PM, Philip Chee wrote: > SeaMonkey uses Form History: > http://hg.mozilla.org/mozilla-central/rev/f69c9019e0b0 Thanks for the reference! I'll keep in mind that these Form History interfaces are used by SeaMonkey as well. From what I see in the patch above, it seems that this wa

Re: Upcoming changes to autocomplete code affecting Thunderbird

On 8/27/2014 9:50 PM, Neil wrote: >> The first changes to autocomplete will land in the next few weeks. >> > So do you have some bug numbers you can quote us? You may want to follow bug 951624 at the moment, though the first interface changes might appear in newly filed dependent bugs. Probably, n

Re: Upcoming changes to autocomplete code affecting Thunderbird

On 8/25/2014 12:56 PM, Mark Banner wrote: > So if I understand you right, we could switch to UnifiedComplete if we > want to maintain multiple search sources (whilst using toolkit code)? UnifiedComplete.js is the Places component that allowed us to replace the autocompletesearch="urlinline history

Re: Upcoming changes to autocomplete code affecting Thunderbird

On 8/15/2014 3:27 PM, Neil wrote: >> It soon became apparent that most of the autocomplete code was >> designed for synchronous operation >> > Synchronous operation of what? Autocomplete works like this: You ask for > some results; some time later, you get some results. How could that be > less syn

Upcoming changes to autocomplete code affecting Thunderbird

As part of a renewed effort to improve the user experience of location bar searches in Firefox, we have been working on the shared code handling search-as-you-type in textboxes [1], which is located in Toolkit. *Current issues* It soon became apparent that most of the autocomplete code was design

Re: Help for new MDN page on testing frameworks (technical and editorial)

On 8/14/2014 10:05 PM, Martijn wrote: > I think an extra column, with what kind of level style test > (Unit/integration/UI) it is, would be nice. I thought about this, but I think the reality is that many of those frameworks are used for multiple type of tests, and most of the column will end up c

Re: Help for new MDN page on testing frameworks (technical and editorial)

On 8/14/2014 1:44 PM, Chris Mills wrote: > I have been through the page and given it a copy edit/styling run. Thanks a lot for that! > Once you do decide to move it over, let me know I've just copied the page contents over the original and set up a redirect on the other page. Feel free to adjust

Re: Help for new MDN page on testing frameworks (technical and editorial)

On 8/13/2014 4:55 PM, Sylvestre Ledru wrote: > Too bad I didn't know about your page before, it would have saved me > quite some time. Well, I just created the page :-) The work for better descriptions in mach and Treeherder is quite useful as well! > By the way, do you know what is talos g1? I d

Re: e10s startup?

On 7/29/2014 9:58 AM, Neil wrote: > How do toolkit components in content processes start themselves up, does > it all have to be done through content scripts loaded by the message > manager? In the case of requestAutocomplete, the code that runs in the child process is activated directly by the DO

Re: Standardized assertion methods

On 6/2/2014 7:08 PM, Ehsan Akhgari wrote: >> On 6/2/2014 4:59 PM, Ehsan Akhgari wrote: >>> I'm _pretty_ sure that the answer is no for >>> mochitest-chrome at least. >> >> Are we running these tests out-of-tree in other environments? > > Do you mean by just opening the page in the browser? I don'

Re: Standardized assertion methods

On 6/2/2014 4:51 PM, Gijs Kruitbosch wrote: > Concretely, IMO in the code you cite there should be a blank line before > each of the 'parent' reassignments. I definitely agree, and I would also use the "Assert." prefix to make the separation between action and check clearer (while if I understand

Re: Standardized assertion methods

On 6/2/2014 4:59 PM, Ehsan Akhgari wrote: > I'm _pretty_ sure that the answer is no for > mochitest-chrome at least. Are we running these tests out-of-tree in other environments? Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https:/

Re: Standardized assertion methods

On 6/2/2014 11:37 AM, Mike de Boer wrote: > Since last Friday[3], each assertion method in Assert.jsm is available in the > global scope of a unit test as well. > Now we can say that the ‘old’ XPCShell-test assertion methods are deprecated > in favour of the Assert.jsm ones. I think it's a very

Re: Uncaught rejections in xpcshell will now cause orange

On 5/28/2014 8:30 PM, David Rajchenbach-Teller wrote: > uncaught promise rejections using Promise.jsm will cause > TEST-UNEXPECTED-FAIL. Fantastic! Promise.jsm rocks! > We intend to progressively extend this policy to: > - DOM Promise (bug 989960). Excellent, this will be a step forward in resol

Re: OS.File design issue from bug 961080 (making downloads respect umask)

On 4/28/2014 7:44 PM, Zack Weinberg wrote: > Based on all discussion to this point, I'm proposing this low-level API: > >fileObject.setPermissions(options); >OS.File.setPermissions(path, options); Thanks for this proposal, it looks like what we need. You'll probably want to tweak the deta

Re: Promise.jsm and the predefined Promise object

On 31/03/2014 13.42, David Rajchenbach-Teller wrote: > I don't remember that we did any benchmark on this. I seem to remember > that this was an assumption based on a discussion with bz a long time > ago, but it might have been someone else. Yes, memory was my source too. On 31/03/2014 13.34, sma

Re: Promise.jsm and the predefined Promise object

On 30/03/2014 22.10, Boris Zbarsky wrote: > Hmm. I don't think it was clear to anyone working on the DOM/ES6 > promises that were were trying to treat them as "do not use" kind of > things. Obviously, that is not what anyone is proposing here :-) DOM Promises are already enabled by default in con

Re: Promise.jsm and the predefined Promise object

On 29/03/2014 21.57, Boris Zbarsky wrote: > For example, it has no Promise.race and no Promise.prototype.catch. It does, as soon as bug 941920 lands. We were holding it off due to compatibility concerns, but the general availability of the DOM Promise object changes the landscape and we're crash-l

Promise.jsm and the predefined Promise object

With bug 988122 landing soon, you'll now find a "Promise" object available by default in the global scope of JavaScript modules. However, this default implementation is still limited, and you're strongly recommended to import Promise.jsm explicitly in new modules: Cu.import("resource://gre/modu

Making sure DOM Promises is on par with Promise.jsm

I have just filed bugs to make sure our DOM Promise implementation is on par with Promise.jsm in these areas: - Make state, value and reason inspectable in the debugger (bug 966471) - Report all unhandled rejections to the Console on GC (bug 966452) - Make handlers inspectable in the debugger (b

Re: Intent to replace Promise.jsm and promise.js with DOM Promises

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

Re: Feature tracking via bug keyword

On 16/10/2013 22.02, Lukas Blakk wrote: > This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now picks > up on the keyword 'feature' in your meta/tracking bugs. I've set the keyword and milestone on bug 907082 but don't see it in: https://wiki.mozilla.org/Features/Release_Trackin

Re: nsIDownloadManager replaced by Downloads.jsm

On 28/08/2013 19.17, sam foster wrote: > However, although Downloads.jsm itself is importable from toolkit, > DownloadsCommon.jsm - which implements a lot of the goodies around it - is > not. Looking though it I see only a couple of methods and > specific-to-desktop-UI references that would pre

Re: nsIDownloadManager replaced by Downloads.jsm

On 03/09/2013 18.08, teramako wrote: > I want to notify to the user when the download is finished. > > on nsIDownloadManager, I write like following: > > Services.downloads.addListener({ > onDownloadStateChange: function (state, download) { >if (download.state === Services.downloads.DOWNLOAD

Re: nsIDownloadManager replaced by Downloads.jsm

On 16/08/2013 10.22, Neil wrote: > Paolo Amadini wrote: >> A new about:config preference named "browser.download.useJSTransfer" >> enables the browser and the Downloads Panel to use the Downloads.jsm >> module instead of nsIDownloadManager as the back-end. The brows

Re: nsIDownloadManager replaced by Downloads.jsm

On 06/08/2013 22.56, garys...@gmail.com wrote: > I flipped on 'browser.download.useJSTransfer' and downloaded some zip files > from Fx inbound Thanks a lot for testing! > and they all were zero byte files. This was done in safe mode. Hope this is > a WIP ;-) This is probably bug 901563, shou

Re: nsIDownloadManager replaced by Downloads.jsm

On 06/08/2013 18.49, Robert Kaiser wrote: > Paolo Amadini schrieb: >> The Downloads back-end will not call any method of nsIDownloadManagerUI >> anymore > > So I cannot implement an alternative download manager any more? You can for sure :-) Anything we're changing and

Use ".then(null, Cu.reportError);" with Promise.jsm

This is a quick reminder to anyone writing or reviewing code that uses "Promise.jsm". You should check that exceptions aren't swallowed, and this is typically done with a logging rejection handler. You should always use the handler unless you're handing off the promise to other code. For some exam

Re: nsIDownloadManager replaced by Downloads.jsm

On 04/08/2013 1.42, Neil wrote: > So nsIDownloadManagerUI is going away too? The Downloads back-end will not call any method of nsIDownloadManagerUI anymore, new downloads should be detected using views. Technically, the interface will still be there for a short time until we refactor the code tha

Re: nsIDownloadManager replaced by Downloads.jsm

On 03/08/2013 19.27, David E. Ross wrote: > Will this break the Preserve Download Modification Timestamp extension > at ? Quite likely. In the new API we'll probably need to add explicit support for this use case, something like a hook of s

Re: nsIDownloadManager replaced by Downloads.jsm

On 03/08/2013 17.26, Neil wrote: > Do I have to watch the download lists globally in order to find out > about new downloads (e.g. from content-disposition: attachment)? Yes, you should add a view to the public and private download lists. > Do I have to emulate cleanUp by calling remove() on all

nsIDownloadManager replaced by Downloads.jsm

Hello, if you are maintaining an add-on or a Mozilla product that interacts with downloads, you should look into updating your code to use the new Downloads.jsm module instead of nsIDownloadManager as soon as possible. While other Mozilla products may migrate at different times, Firefox for Deskt

Re: XPIDL & Promises

On 30/07/2013 16.20, janjongb...@gmail.com wrote: > From code I can use Cu.import("resource://gre/modules/Promise.jsm"); to use > promises. But is it possible to have a promise as a return type in my .idl > file (b2g)? For the record, if you want to pass a "Promise.jsm" promise through an XPCOM

Re: XPIDL & Promises

On 30/07/2013 22.40, Andreas Gal wrote: > Whats the main pain point? Whether promises are resolved immediately or > from a future event loop iteration? That. The migration from "core/promise.js" to "Promise.jsm" should address consumers expecting callbacks to be called immediately. "Promises.jsm"

Heads up: JavaScript API for downloads

Hello, I wanted to mention that work on the new JavaScript API for downloads is proceeding steadily. If you're working on code related to downloads, this is probably going to be relevant to you over the next few months, even though initially the project is focused on Firefox for Desktop. More fre