J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Description • 10 years ago

Chrome 33 added support for linking the call stack of something async back up to the original call site that scheduled the async behavior (setTimeout, etc.).

Seems like a neat idea for us to consider too.  A little more info is available on their post[1].

[1]: http://www.html5rocks.com/en/tutorials/developertools/chrome-33/#toc-asynchronouscallstacks

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 1 • 10 years ago

Our plan was to add a new console.tagStack() method for the user to opt in to the additional data collection, but it's interesting that they do this automatically. Perhaps the CPU and memory cost isn't that bad after all.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 2 • 10 years ago

It's not super obvious from Chrome's screenshot, but the "Async" checkbox that appears next to the "Call Stack" panel actually has to be enabled before your code runs.  If you hit a breakpoint and then enable "Async" after the fact, no extra information appears (which is slightly confusing UX).

I have no idea if this was done for performance reasons, or simply because they can't gather new information once you hit a breakpoint.  It does not appear to degrade performance noticeably, but I also haven't tested very much.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 3 • 10 years ago

Was talking to Erik Bryn (the Ember dude) about this at DHTMLConf.

We should totally do this automatically for users (what Chrome is doing now; this bug) but also expose the console.tagStack() method (bug 882825) for user land tagging. Ember manages its own event loop of sorts and they'd love to be able to link where something came from originally instead of only showing a ton of Ember-internal frames.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 4 • 10 years ago

We will have most of the infrastructure for this completed once bug 961325 lands.

	stefan.penner
	Comment 5 • 10 years ago

This is quite awesome!

Also just a note: user-land micro-task queues are quite common, in addition to embers run-loop, literally every promise implementation does this as well.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 8 • 9 years ago

Paolo, I'm not sure we should enable async stacks by default on 39 for Beta, given that there is still work in progress on bug 1142577 and issues mentioned in bug 1152893. Which other bugs should block enabling this on Beta? Is this ready to ride the trains? We may need to make sure it gets turned off for Desktop as well as mobile?

	Honza Bambas (:mayhemer)
	Comment 9 • 9 years ago

Please see also bug 981514.  It aims for probably the same goal and my experimental work I currently have already gives full walk back (and more.)  I'll blog about it soon.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 10 • 9 years ago

(In reply to Honza Bambas (:mayhemer) from comment #9)
> Please see also bug 981514.  It aims for probably the same goal and my
> experimental work I currently have already gives full walk back (and more.) 
> I'll blog about it soon.

You linked to this bug :P

	Honza Bambas (:mayhemer)
	Comment 11 • 9 years ago

Interesting mistake :)

The bug I mean is bug 1148204.

	:Paolo Amadini
	Comment 12 • 9 years ago

(In reply to Liz Henry (:lizzard) from comment #8)
> Paolo, I'm not sure we should enable async stacks by default on 39 for Beta,
> given that there is still work in progress on bug 1142577 and issues
> mentioned in bug 1152893.

Hi, sorry for the delayed reply. I agree that the before the Async Stacks feature merges to Beta 39 we have to get to a state of consistency as discussed in bug 1152893.

The way backwards (and the most likely one for this cycle) would be to back out bug 1140472 (Set an async stack when invoking promise handlers) from late Aurora 39. There might still be other tests written or modified after that bug landed, that depend on it - Nick or Boris will probably be able to help if needed.

> Which other bugs should block enabling this on Beta?

The way forward is to implement bug 1142577 (Use JS::AutoSetAsyncStackForNewCalls for setTimeout and setInterval) and bug 1158133 (Add a way to disable async stacks, and disable by default on mobile platforms).

> Is this ready to ride the trains? We may need to make sure it gets
> turned off for Desktop as well as mobile?

In fact we may also get bug 1158133 done on its own and turn off the feature on both Desktop and mobile for the 39 cycle. It's unlikely that I'll have time to work on it however, and I'm not familiar with the steps required in the JS engine.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 13 • 9 years ago

Thanks for the detailed answer!  Looks like Nick is out until May 17, Boris is usually quite busy, so can you follow up with this so we can make a decision one way or the other on this and straighten it out by Friday May 8. It sounds like what we need to do is back this out for 39.  I would like that to happen before 39 goes to beta, not after.

	:Paolo Amadini
	Comment 14 • 9 years ago

I'm testing a backout of bug 1140472 on mozilla-central, let's see how it goes.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=9fa1cf7d9b5e

	:Paolo Amadini
	Comment 15 • 9 years ago

Looks like there are a few tests to adjust, but should be quite easy. Filed bug 1163139 which will likely see a patch tomorrow.