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
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
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
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
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 has a valid use case
will still
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, should
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 browser must
be restarted for the preference
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 ===
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
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:
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
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
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:
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
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
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, smaug
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
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
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
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
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 DOM
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
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
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
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
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,
new
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 way
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
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
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
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 these as errors
To clarify
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
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
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
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
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
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 })
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
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
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
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
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
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 between
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 follow-ups?
Please file
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
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
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
47 matches
Mail list logo
