Runnable labeling for Quantum DOM

[Bill McCloskey]

Hi everyone,

As part of the Quantum DOM project, we're going to be "labeling" all
runnables in the browser to say which document they're operating on.
Labeling will allow us to prioritize some documents over other documents as
well as running different documents concurrently. An API for labeling has
landed in bugs 1305926 and 1320753. Some initial work to label common
runnables is ongoing in bug 1318506.

The only way we can feasibly finish this project is to get help from
everyone working on Gecko. Most runnables are pretty easy to label if you
understand what the code is doing. And if you don't already understand the
code, it's a great way to learn :-).

We have a wiki page that describes the details of labeling:
https://wiki.mozilla.org/Quantum/DOM
You can find examples of labeling in bug 1318506.

If you need more help understanding what's going on, you can contact me
(:billm), Ehsan (:ehsan), Olli (:smaug), or Ben Kelly (:bkelly). We're
going to have a session on Quantum DOM at the Hawaii work week.

I'll send out another email about this after Hawaii with more information
on logistics. If you want to get started before that, please make sure to
file a bug on what you're doing before you start. That should avoid
duplicating work.

Thanks,
Bill

[Boris Zbarsky]

On 12/1/16 10:40 PM, Bill McCloskey wrote:
> As part of the Quantum DOM project, we're going to be "labeling" all
> runnables in the browser to say which document they're operating on.

Is the intent basically to get rid of NS_DispatchToMain/CurrentThread,
or at least get their usage down to a minimum?

> If you want to get started before that, please make sure to
> file a bug on what you're doing before you start. That should avoid
> duplicating work.

Is there an overall tracking bug people could check to see which things
are already filed or in-progress?

-Boris

P.S. This is awesome. ;)

[Kyle Huey]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> P.S. This is awesome. ;)

Indeed. So glad this is finally happening.

- Kyle

[Johnny Stenback]

Double indeed! Very cool to see this happening!

On a logistical note, do we have a meta bug that could track all the bugs
about labeling etc, so that we can hang individual bugs off of that one to
help avoid multiple bugs being filed and worked on for the same thing?

Thanks!


- jst

On Thu, Dec 1, 2016 at 8:31 PM, Kyle Huey <m...@kylehuey.com> wrote:

> On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> > P.S. This is awesome. ;)
>

> Indeed. So glad this is finally happening.
>
> - Kyle

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Andrew McCreight]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> If you want to get started before that, please make sure to
>> file a bug on what you're doing before you start. That should avoid
>> duplicating work.
>>
>
> Is there an overall tracking bug people could check to see which things
> are already filed or in-progress?
>

I filed bug 1321812 just now to use as a meta bug.

>
> -Boris
>
> P.S. This is awesome. ;)
>

[Johnny Stenback]

Excellent, thank you!


- jst

On Fri, Dec 2, 2016 at 7:28 AM, Andrew McCreight <amccr...@mozilla.com>
wrote:

> On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>

> > If you want to get started before that, please make sure to
> >> file a bug on what you're doing before you start. That should avoid
> >> duplicating work.
> >>
> >
> > Is there an overall tracking bug people could check to see which things
> > are already filed or in-progress?
> >
>

> I filed bug 1321812 just now to use as a meta bug.
>
>
>
> >

> > -Boris
> >
> > P.S. This is awesome. ;)
> >

[Tom Tromey]

>>>>> "Bill" == Bill McCloskey <wmccl...@mozilla.com> writes:

Bill> As part of the Quantum DOM project, we're going to be "labeling" all
Bill> runnables in the browser to say which document they're operating on.

I wonder whether this can be used to fix the various "run to completion"
bugs we've encountered in the debugger. I don't know if I understand
the problems there well enough to do them justice, but basically the
issue is that the debugger needs to delay some runnables but not others,
and the approach currently used lets some slip through. This shows up
in a very confusing way for the user, like some XHR callbacks still
being invoked while supposedly paused in the debugger.

The meta bug for the devtools side of this is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1074448
It has links to all the scenarios where we've encountered the bad behavior.

The wish-list fix is:
https://bugzilla.mozilla.org/show_bug.cgi?id=715376
aka "implement per-page event queue, to allow timeout grouping/prioritization/etc".
I wonder specifically if Quantum DOM is going to fix this one.

thanks,
Tom

[Ehsan Akhgari]

Once the labeling of runnables is finished, we will know which DocGroup
(or TabGroup if the DocGroup isn't known at runnable dispatch time) a
runnable belongs to. For the Quantum DOM project purposes we will
probably end up splitting the event queue into one queue per TabGroup.
That way, not running a TabGroup would be as simple as skipping over the
queue belonging to the TabGroup from the main event loop.

With this infrastructure in place, we should be able to "suspend" an
entire TabGroup when a page inside it is being debugged, for example.
Or something similar along those lines, depending on what the exact
needs from the devtools side are. That way, things such as XHR
callbacks will be runnables waiting in the suspended TabGroup's queue,
which will be processed when the TabGroup is resumed.

(Note that we may also be able to do this at the DocGroup level for
devtools, if that's more appropriate.)

Does this sounds like a useful answer?

Cheers,
Ehsan

[Ehsan Akhgari]

On 2016-12-01 11:21 PM, Boris Zbarsky wrote:
> On 12/1/16 10:40 PM, Bill McCloskey wrote:
>> As part of the Quantum DOM project, we're going to be "labeling" all
>> runnables in the browser to say which document they're operating on.
>
> Is the intent basically to get rid of NS_DispatchToMain/CurrentThread,
> or at least get their usage down to a minimum?

We won't get rid of them. For one thing, this project is really focused
in the stuff that happens on the main thread of the content process, and
those APIs are used elsewhere. But yes, the usage of those APIs should
go down to a minimum.