<div dir="ltr"><div class="gmail_extra"><br>On Thu, Mar 16, 2017 at 9:08 PM, Michael Layzell <span dir="ltr"><<a href="mailto:michael@thelayzells.com" target="_blank">michael@thelayzells.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I mostly use tasks when writing tests, so I mostly have questions about how it's use in that situation will be affected.<br></div><div><br>Can we pass async functions everywhere where we use `add_task` in tests already? If we can't, is there a tracking bug for converting all of the test systems to support it?<br></div></div></blockquote><div><br>We've been doing this in sync's tests (<a href="https://dxr.mozilla.org/mozilla-central/source/services/sync/tests/unit/test_bookmark_validator.js#17" target="_blank">example</a>) since shortly after 
async/await became available with good results.<br><br>The biggest 
disappointment has been stack traces, which we hoped would improve some 
with async/await, but have more or less stayed equivalently generic and 
opaque (although it's not clear to me if this is only due to still 
having some code using tasks, such as add_task, introducing all that 
machinery). But this isn't a regression compared to using Task.js, we had just been hoping for an improvement (this hope was actually our biggest motivation for switching, IIRC).<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Can you `await` a function created with Task.async such as `BrowserTestUtils.withNewTab` during the transition period?<br></div></div></blockquote><div><br>Yes, await generally just expects a function returning a promise (although I believe its okay to await on a function that returns synchronously, and that it will be equivalent to it being wrapped with Promise.resolve).<br><br>The 
way it was explained to me is that `let x = await foo(); ...` desugars 
to `Promise.resolve(foo()).then(x => { ... })`. I'd certainly 
appreciate being corrected if I'm wrong, though.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>How about in ESR52? Will uplifting tests to ESR52 be a painful experience due to having to use different tools to write the tests?<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Can I pass an async function as the callback argument to things like ContentTask.spawn and BrowserTestUtils.withNewTab? How about on ESR52?<br></div></div></blockquote><div><br></div><div>If you can pass a function returning a promise in, and have everything do the right thing, yes. From taking a look at their source, this *seems* to be the case, but I could be wrong (and I'm sure someone will correct me if I am).<br><br></div><div>I don't know if it's okay to use in ESR52, but it does appear that <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1185106" target="_blank">bug 1185106</a>, which implemented async functions, landed in 52, but I also recall being told to wait for 53 before using it.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-m_6082547908261844172gmail-h5">On Thu, Mar 16, 2017 at 7:18 PM, J. Ryan Stinnett <span dir="ltr"><<a href="mailto:jryans@gmail.com" target="_blank">jryans@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_6082547908261844172gmail-h5">Sounds like a good change to make from the discussion so far.<br>
<br>
If there are issues with stack traces, I would assume having more of our<br>
code base using async / await is a good way to apply pressure for stack<br>
trace improvements (if needed) that will benefit everyone.<br>
<br>
- Ryan<br>
<br>
On Thu, Mar 16, 2017 at 5:52 PM, Kris Maglione <<a href="mailto:kmaglione@mozilla.com" target="_blank">kmaglione@mozilla.com</a>><br>
</div></div><div class="gmail-m_6082547908261844172gmail-m_1935052768074542828HOEnZb"><div class="gmail-m_6082547908261844172gmail-m_1935052768074542828h5"><div><div class="gmail-m_6082547908261844172gmail-h5">wrote:<br>
<br>
> On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:<br>
><br>
>> For modules that have already converted, is there any performance change<br>
>> (good or bad) between async / await vs. Task?<br>
>><br>
><br>
> I haven't noticed any differences either way, but I also haven't done any<br>
> explicit profiling. There's definitely a difference in the way we collect<br>
> async stacks in async/await code vs. with the Promise.jsm promises that<br>
> Task.jsm uses, but that shouldn't show up much on release.<br>
><br>
><br>
> On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione <<a href="mailto:kmaglione@mozilla.com" target="_blank">kmaglione@mozilla.com</a>><br>
>> wrote:<br>
>><br>
>> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:<br>
>>><br>
>>> Writing code in standard JS is always better for the web, makes it easier<br>
>>>> to onboard new engineers and allows for better support in developer<br>
>>>> tools.<br>
>>>> So I'd like to propose that we switch to the standard way of writing<br>
>>>> these<br>
>>>> functions immediately. New code should use async/await instead of<br>
>>>> Task.jsm<br>
>>>> going forwards.<br>
>>>><br>
>>>><br>
>>> +1<br>
>>><br>
>>> I've already started doing this in places where using Task.jsm was<br>
>>> unwieldy, and it's improved things tremendously.<br>
>>><br>
>><br></div></div><span class="gmail-m_6082547908261844172gmail-">
______________________________<wbr>_________________<br>
dev-platform mailing list<br>
<a href="mailto:dev-platform@lists.mozilla.org" target="_blank">dev-platform@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-platform" rel="noreferrer" target="_blank">https://lists.mozilla.org/list<wbr>info/dev-platform</a><br>
</span></div></div></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
<br></blockquote></div><br></div></div>