Thanks for the repro.

Scheduler folks, long tasks are tracked here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager_impl.cc?rcl=aed822394c4b7dc30c615bf70db1574aa62de5cd&l=408

It looks like we should be instrumenting microtask execution as well. I suspect we're missing this in a bunch of places - likely EQT and CPU time computation? Is microtask execution run through the TaskQueueManager? Should it be?

Note on the demo - I had to add mode:no-cors to get the demo to work.
https://output.jsbin.com/fobigah/quiet

Here's a slightly modified demo, which just spits things out to the console:
https://output.jsbin.com/hiqarek/quiet

Parking on myself for the moment.

At the moment microtasks are run inside task observers: TaskQueueManager dispatches notifications to the observers [1] and one of these observers runs microtasks [2].

I strongly dislike task observers (e.g. they are not tracked by our infrastructure at the moment). Microtasks are one of the legitimate use cases for task observers-like scenario. I believe that we should support them natively instead of relying on task observers: an explicit call (RunMicrotasks()) inside TaskQueueManager will allow for better integration with our metrics.

The other question that I have is whether the microtasks can be attributed to the task they run after. I assumed that some microtasks can come from a different place altogether, but I'm not quite sure.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager_impl.cc?type=cs&sq=package:chromium&l=425
[2] https://cs.chromium.org/chromium/src/gin/isolate_holder.cc?type=cs&q=AddTaskObserver+v8&l=127

Explicitly including RunMicrotasks() inside TQM sounds much better to me.

What do you mean by "attributed" to the task they run after?

Does this refactor feel like something you (or someone in London) would have time for in the not-too-distant future?

This has a pretty strong negative impact on metric quality.

Otherwise, I think we can wait until npm@ is back next week.

Re #4: I'm not sure I can commit myself, unfortunately. I'll be quite happier if npm@ can drive this, I'd most happy to consult.

By "attributed" I mean that there is a simple solution -- treat the task length as task itself + observers for all purposes, including metrics and PerformanceObserver. However, I'm not familiar with microtasks and I assumed that the following scenario is possible: task A
(let's say fetch) runs first and triggers a (delayed) microtask (resolving .then in the example above). Task B (let's say timer) runs second and after it both microtasks from tasks A and B are run. In the approach described above we'll "blame" task B for all microtasks. 

Probably we need to task to some V8 folks and get clarification here.

Alright, assigning to npm@ to deal with once he's back.

I'm wondering if there's a new task type (i.e., task runner) that is needed here since the semantics of microtasks are a little weird and a task observer or a direct call in TQM doesn't really match them (e.g., there's no need to run microtasks after internal scheduler control tasks). It might be helpful to take another look at the spec[1] and figure out what primitive we really need.

[1] https://html.spec.whatwg.org/#microtask-queue

I have a few other things on my plate before tackling this: 

- bug 875401 (estimated time ~1 week)
- bug 859914 (estimated time ~1-2 weeks)
- bug 862389 (estimated time ~1-2 weeks)

I also have one week of vacation in early September. Given all of that, I'll set a NextAction date at the earliest possible time at which I might be working on this and give an update then.

 Issue 881846  has been merged into this issue.

The NextAction date has arrived: 2018-09-10

Taiju, is there any update for this?