►
From YouTube: WebPerfWG TPAC 2020 meetings - October 19 - part 2
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
we're
back
from
break
and
we're
still
recording
and
scott
will
talk
about
main
thread,
scheduling
apis.
C
Thanks,
so
what
I
wanted
to
do,
maybe
a
little
different
from
the
last
couple
times
I
presented.
C
This
group
is
give
more
of
a
higher
level
view
overview
of
of
the
space
that
we're
working
in
and
kind
of
break
it
into
a
few
parts
like
the
apis
that
we're
you
know
currently
working
on
that
are
available
to
experiment
with
apis
that
we,
you
know
where
we
see
the
the
next
direction,
what
we're
going
to
spend
our
time
working
on
after
that
and
some
things
that
are
a
little
bit
farther
off
so
like
I
said,
I
want
to
keep
this
a
little
bit
high
level,
not
drill
too
deep
into
designing
things,
but
want
to
also
leave
plenty
of
time
at
the
end
for
discussion
on
things
that
people
are
interested
in
okay,
so
that
the
first
section
is
the
apis
that
you
know
we've
been
working
on
and
that
are
currently
available
to
experiment
with.
C
So
I've
presented
this
to
this
group
a
few
times
now,
scheduler.posttask
and
the
main
gist
of
it.
Is
it's
a
it's
a
api
that
allows
developers
to
prioritize
task
scheduling,
there's
an
explainer
link
there.
It
enables
and
I'll
show
an
example
on
the
next
slide,
but
what
it
does
is
it
enables
course
grain
coordination
by
exposing
a
few
semantically
meaningful
priorities,
so
we
expose
user
blocking,
which
is
the
highest
priority
user
visible
and
background,
and
the
idea
is
that
the
browser,
then
the
browser
scheduler,
can
use
that
to
schedule.
C
Amongst
you
know,
tasks
scheduled
with
post
task
and
also
it
can
use
it.
You
know
as
a
hint
to
coordinate
between
other
tasks
that
it
has
pending,
and
a
key
feature
is
that
the
tasks
are
controllable.
So
you
we,
we
enable
dynamic,
reprioritization
and
cancellation
based
on
task
controller,
which
is
an
extension
of
the
abort
controller
class
and
maybe
importantly
like
saying
here
that
this
is
a
kernel
that
we
can
build
on.
C
C
You
queue
a
callback,
add
a
priority
and
it
gives
you
a
promise,
that's
resolved
when
the
task
finishes
so
yeah,
that's
just
basic
api
shape
and
going
from
there,
like,
I
said,
one
of
the
key
features
is
that
you
can
control
these
tasks.
So
maybe
the
key
takeaway
here
is
that
you,
you
create
a
task
controller
object
in
a
similar
way
that
you
create
an
abort
controller
object
that
has
for
using
the
fetch
api
and
some
others.
C
I
believe,
and
and
that
has
a
signal
property
and
that
signal
can
be
passed
to
post-task
when
you're
scheduling
tasks
and
that
allows
you
to
control
a
whole
group
of
tasks
together
on
mass.
So
you
can
cancel
them
using
abort,
just
as
you
would
with
you
know,
fetch,
and
you
can
also
the
thing
that
we
add
is
being
able
to
change
the
priorities
so
that
you
can
change
the
priority
of
anything
that
has
that
signal
associated
with
it
any
tasks.
C
So
that's
the
the
basis
of
the
kind
of
the
you
know.
Mvp
of
of
this.
The
status
of
it
is
that
were
it's
currently
available
in
origin
trial.
So
the
api
hasn't
really
changed
since
I
presented
this,
I
think,
maybe
last
november,
at
that
point
we
you
know
we
worked
on
getting
it
ready
for
origin
trial.
C
We
were
set
back
quite
a
bit
with
partners
with
covid,
so
we
didn't
get
a
lot
of
meaningful
data
out
of
the
first
round
of
experimentation,
so
we
just
extended
it
for
m86
and
m87
in
chrome.
So
anybody.
C
To
experiment,
please
sign
up
available
through
early
2021
react
and
airbnb.
Two
of
our
close
partners
are.
C
C
The
page
when
you're
interacting
with
it-
and
they
want
to
use
this
to
do
better
task
scheduling,
so
they're
really
excited
to
experiment.
Just
some
other
notes,
you
know
tag
review.
We
completed,
there's
still
a
number
of
open
questions
around.
You
know
ordering
guarantees
that
we're
going
to
provide
what
you
know
exactly
is
needed,
for
you
know,
shipping,
how
much
value
does
justice
mvp
provide
which
we're
looking
to
get
in
origin
trials?
C
So
I
think
for
us,
the
next
steps
are
getting
the
feedback
on
origin
trial
and
seeing
where
we
go
from
there.
So
that's
about
it
for
post
task,
so
a
follow-up
to
that
is
signal
inheritance.
So,
as
I
mentioned,
the
the
signal
is
this
object
that
you
can
pass
to.
You
know
associate
with
a
group
of
tasks,
and
one
common
thing
that
comes
up
is
that
folks
want
to
be
able
to
inherit
that
signal
to
do
priority
inheritance.
C
A
key
here
is
that
you
need
to
you
can't
just
inherit
the
priority,
but,
inheriting
the
signal
allows
these
subtasks.
If
you
will
to
listen
for
priority
changes,
so
we've
built
an
api
scheduler.current
that
allows
you
know,
enables
developers
to
read
the
context
of
the
current
task
and
I'll
show
an
example
of
this
on
this
next
page
here.
C
So
scheduler
has
a
current
test
signal
that
that
is
the
signal
that
the
task
was
originally
scheduled
with
and
that
allows
subtasks
to
be
scheduled
using
that
same
information,
so
it
automatically
will
inherit
the
context
which
consists
of
both
the
priority
and
the
you
know,
cancellation
part
of
it.
C
A
key
feature
of
this
is
that
it's
it's
inheritable
across
async
boundaries
so
like
in
this.
In
this
example,
here
we
have
a
task
that
is
scheduled
with
post
task
with
some
signal,
and
we
can
pass
that
signal
to
other
post
tests
right
and
it's
reading
it.
It's
reading
it
across
a
couple
async
boundaries.
I
mean
it
doesn't
look
like
it.
C
You
know
it's
an
async
function,
so
it
looks
synchronous,
but
we're
actually
saving
and
restoring
that
signal
across
promise
boundaries
which
is
really
kind
of
the
killer
feature
of
this,
and
the
thing
that's
oft
requested.
C
The
alternative
here
is
that
the
you
know
the
developer
would
have
to
track
that
signal
manually
and
and
pass
it
to
another.
Whatever
you
know
functions
that
it
wants
to.
So
just
a
note
about
the
you
know
the
status
here
there
is
some
risk
involved.
You
know
this
is
something
that
I
think
facebook
with
react.
Folks
really
really
wanted
at
first,
but
they've
implemented
their
own
version
of
this,
and
they
found
that
you
know
in
practice.
C
This
can
be
quite
difficult
to
get
right,
so
this
is
something
that
we're
keeping
an
eye
out
for
so,
for
example,
you
run
into
this
problem
of
viral
propagation,
where
you
know
you
inherit
the
you
inherit
the
context
of
some
task,
but
then
everything
ends
up
sooner
or
later.
C
Everything
on
the
page
ends
up
being
prioritized
to
the
highest
level,
which
is
not
exactly
what
they
intended
right
like
if
they're,
inheriting
the
the
context
from
some
high
priority
update,
you
run
into
a
problem
where
priorities
essentially
become
meaningless
because
you've
gone
way
too
far
with
with
inheritance.
So
we
are
keeping
that
in
mind.
I
think
for
us
for
status
like
we've
built
this
there's
an
explainer
for
it,
it's
in
the
post-task
origin
trial,
but
it's
unclear
if
we'll
pursue
shipping
this
or
maybe
changing
the
api
shape.
C
So
that's
is
there
any
questions
on
the
those
couple
apis
that
we
have
available
for
experimentation
before
I
move
into
some
other
stuff,
we're
working
on.
E
C
Yeah,
so
that
that's
a
great
question
and
it's
something
that
obviously
with
with
priorities
we
are,
we
are
very
concerned
about
there's
this
trade-off
between,
like
giving
developers,
strict
guarantees
and
giving
the
browser
more
control
to
do
things
like
that.
So,
first
of
all,
starvation,
starvation
is
only
a
possibility
within
the
post-task
api,
not
necessarily
as
much
like
we
give.
The
browser
has
control
to
order
post-task
tasks
and
non-post-test
tests.
Any
way
that
it
wants
to
so
starvation
is
is
fairly
isolated
just
to
postdesk
and
now
yes,
there
is
a
risk.
C
The
way
that
we're
we're
doing
this
at
first
is
our
first
pass
at.
It
is
strict
priority
order
from
from
the
highest
bucket
to
the
lowest
bucket.
That's
one
of
the
things
we
want
to
look
out
for
in
origin
trial
and
get
feedback
from
developers
as
to
whether
or
not
that's
the
problem,
like
are
things,
and
we
have
metrics
implemented
that
we're
going
to
measure
this
through
origin
trial
to
understand
how
long
the
lower
priority
work
is
waiting.
C
So
I
think
that's
something
that
we
can
fix
in
a
number
of
ways
if
it
does
become
a
problem,
but
it's
something
that
we're
gonna
essentially
keep
an
eye
out
for,
and
you
know
figure
out
what
to
do.
When
we
see
the
extent
of
it.
C
This
is
kind
of
where
our
team's,
you
know,
current
direction
is,
and-
and
some
of
this
has
been
fallout
from
you
know-
we've
presented
the
api
to
a
number
of
groups
and
a
number
of
partners
that
we're
working
on
and
some
of
the
things
that
we've
heard
and
I've
identified
as
being
a
couple
of
the
more
important
points.
So
the
probably
the
the
you
know,
key
amongst
them
is
yielding
and
long
tasks,
and
I
know
this
has
come
up
with
this
group.
I
presented
you
know
a
previous
proposal
on
this
topic.
C
It's
come
up
in
the
context
of
his
input
pending.
Essentially,
you
know
you
have
a
long
task
and
you've
determined
by
some
method
that
now
is
a
good
time
to
build
either
because
you
know
you've
run
for
some
amount
of
time
and
think
an
animation
is
pending
or
you
determine
that
is
input
pending
or
you
just
want
to
be
a
good
citizen
and
yield
after
some
amount
of
time.
C
So
the
current
state
of
the
art
here
is
that
you
schedule
some
sort
of
continuation
task
with
a
timeout
or
a
post
message,
depending
on
which
kind
of
scheduling
api
you're
using
and
the
the
problem
here
is
that
you
know
you
kind
of
you
may
give
up
your
place
in
line
is
one
problem,
so
there's
a
performance
penalty
that
you
you
pay
if
you're,
if
you're
yielding
that
some
folks
are
worried
about.
Also
you
know
it's
just
not
the
most
ergonomic.
C
You
know
way
to
to
do
this,
to
reschedule
continuation
and
we're
wondering
if
we
can
do
better
like
our
our
goal,
primarily
there's
two
one
is
to
enable
and
encourage
yielding.
We
want
to
encourage
developers
to
break
up
long
tasks
by
giving
them
some
sort
of
ergonomic
api,
and
also
we
want
to
reduce
the
performance
penalty
that
you
pay
for,
yielding
at
least
experiment
and
see
how
much
better
we
can
do.
C
I
let
you
know,
apps,
regain
control
more
quickly,
after
yielding
secondary
to
that.
I
think,
is
you
know
this
thing.
That's
come
up
a
couple
times
with
this
group,
which
is
yield
to
certain
things
right.
There's,
like
you
know,
if
is
input
is
impending,
is
true,
and
you
want
to
yield
to
something
specifically
really
isn't
our
primary
goal
right
now,
but
I
think
it's
something
that
we
you
know
should
can
consider
in
the
api,
maybe
in
a
later
time.
C
Right
now,
you
know
this
has
come
up
a
bit
through
partner
feedback,
which
has
been
kind
of
interesting,
like
I
think,
we've
learned
from
partners
just
experimenting
with
the
post-test
api
that
yield
and
post-test
goes
hand-in-hand
right.
Like
I'm
posting
this
task,
one
option
is
to
just
post
many
subtasks,
but
it's
not
as
natural
for
developers
to
do
when
they
have
one
longer
task
that
they
want
to
insert
yield
points
into.
C
So
previously
we
had
a
proposal
for
a
specific,
a
yield
api
very
broad,
like
scheduler.yield.
It
returns
a
promise
and
you
can
await
that
and
the
browser
would
do
other
work
and
then
reschedule
or
fulfill
the
promise
when
the
after
the
yield
had
finished
we're
interested
in
exploring-
and
this
is
all
very
high
level
at
this
point-
and
we
don't
have
you
know
a
great
proposal
for
this,
but
we're
interested
in
narrowing
the
scope.
C
A
little
bit
potentially
just
to
post-task
there's
some
things
that
we
may
want
to
punt
on
for
now
around
yielding
such
as
like
what
happens
if
you
yield
in
wrath
or
what
happens
if
you
yield
in
event,
handlers
and
things
like
that,
and
we
think
you
know
it's
possible
to
maybe
scope
this
a
little
bit
more
narrowly
just
to
post-task
as
we're
working
on
a
dedicated,
post-test
api,
and
I
think
that
may
actually
open
up
a
few
options
for
us
that
we're
kind
of
excited
about
so
one
option
that
we're
going
to
be
exploring
is
whether
or
not
we
can
integrate
generator
functions
with
post
task.
C
So
if,
for
I'm
sure
folks
here
are
aware
of
generators
like
generators
like
have
yield
syntax
right,
so
you
can
yield
inside
of
a
generator
which
returns.
You
know
control
back
to
the
the
calling
point.
So
we
could
we
could
instrument,
or
we
could
make
post
task
understand.
Generators
is,
is
one
option
that
we
have
here,
rather
than
using
this
whole
separate
yield
api.
If
you
post
task
a
generator
function,
we
could
turn
that
into
a
ualb
function,
so
actually
be
really
curious.
C
If
folks
have
you
know
immediate
reactions
to
that,
it's
something
that
we're
you
know
kind
of
excited
about,
trying
out
at
least
and
and
at
least
exploring
the
options
kind
of
the
the
you
know.
The
next
next
steps
for
us
anyways
are
to
try
to
write
this
up
and
and
compare
various
options,
and
then
maybe
take
this
back
to
this
this
group.
But
if
anybody
has
immediate
reactions
to
that,
I'd
be
happy
to
hear
it.
F
C
Yeah,
it's
we're
kind
of
inverting
things
a
bit
which
is
like,
maybe
the
the
odd
thing
here
where
the
browser
becomes
the
client
of
this
function,
but
it
also
kind
of
works,
and-
and
I
mean
you
could
imagine
even
extending
this
to
the
like-
I
want
to
yield
for
specific
things
by
yield
returning,
you
know
if
you
yield
an
object
that
has
information,
that's
how
you
could
communicate
back
to
the
browser.
C
I
think
the
exciting
part
for
us
is
just
how
easy
it
is
to
you
know,
insert
yield
points.
We
could
work
with
both
async
and
sync
code,
which
also
is
a
nice
advantage,
but
I
don't
know,
I
think
we
need
to
understand,
maybe
all
of
the
trade-offs
a
little
bit
better,
but
it's
something
that
I
think
it
could
work
and
it
does
make
you
know
it
lends
itself
nicely
to
post-test.
I
think.
C
Cool,
so
right,
so
anyways,
yeah
yield
is,
is
kind
of
high
on
the
list
and
something
that
like
we
may
want
to
think
about.
Even
in
the
you
know,
one
of
post-task,
I
think
we'll
learn
a
little
bit
more
from
origin
trial,
but
we'll
be
exploring
this.
You
know
soon.
C
The
the
next
thing
that
we're
working
on
kind
of
immediately
is
app
specific
priorities,
so
I
had
mentioned
that
posttest
supports
very
granular
semantically,
meaningful
priorities
that
you
know
helps
the
browser.
I
think,
more
than
anything
be
able
to
use
these.
C
So
a
common
problem
in
a
frequently
asked
question
is
we
have
a
lot
of
a
lot
of
partners,
a
lot
of
folks
that
develop
their
own?
You
know
schedulers
and
and
there's
a
varying
degree
of
priorities
like
so
one
may
have
five
priorities.
Another
may
have
11
priorities
like
it
all
over
the
place
like
in
a
lot
of
times.
This
is
a
generalized
like
priority
queue,
implementation
that
they
use.
C
Developers
want
to
you
know,
keep
this
behavior.
They
need
to
build
cues
on
top
of
post-task,
which
makes
it
a
little
bit
more
a
little
bit
more
difficult.
I
would
say
for
them
to
adopt
like,
I
think
what
we're
seeing
is
a
strong
desire
for
developers
to
be
able
to
just
hand
their
tasks
and
not
have
to
you
know,
manage
them
in
this
world,
so
we're
exploring
some
options
of
how
we
can
you
know
include
this
in
post-task.
C
So
one
proposal
that
you
know
it's
very
preliminary
stage
just
looking
for
feedback
at
this
point
is
by
adding
an
option
for
like
a
rank,
and
this
rank
is
essentially
like
the
order
within
a
priority
queue
within
the
broader
granular
buckets,
and
this
could
work.
But
there's
a
big
challenge
is
scheduling
boundaries
because,
as
I
mentioned
different,
you
know
there
will
be
different
ranking
systems
on
the
page
and
ideally
we'd
like
to
be
able
to,
at
the
browser's
perspective,
be
able
to
schedule
between
them
right.
C
So
if
you
have
one
you
know
party
on
the
page
that
has
rank
from
0
to
10
and
another
that
has
0
to
30,
we
may
want
to
alternate
between
them
in
some
sort
of
way
within
the
highest
priority
down
to
the
lowest
priority.
So
it's
a
challenge
here
that
we're
still
kind
of
you
know
working
out
details
on
how
we
would
accomplish
that,
but
another
area
that
we
think
developers
have
definitely
expressed
interest
in
us
trying
to
provide
some
some
sort
of
integration
with
post-task.
A
So
it's
unclear
to
me
how
you
would
reconcile
multiple
ranking
systems
from
different
parties.
Will
you
just
put
them
all
in
a
single
queue
based
on
the
same
rank
or
will
you
have
some
ways
for
the
different
parties
to
define
their
rank
systems
and
then
somehow
normalize
based
on
that.
C
I
mean
that
that
could
be
an
option
like
I
think
originally.
My
thought
was
that
a
signal,
if
you,
if
you
provide
a
task
signal
that
indicates
that
the
priority
can
change
right.
So
if
the
priority
can
change
independent
of
other
tasks,
then
you've
kind
of
created
a
some
sort
of
boundary,
but
it's
just
not
clear
that
developers,
if
that
will
work
for
them
and
we're
kind
of
working
with
partners
right
now
to
understand
what
ordering
guarantees
they
want
right
from
the
browser's
perspective,
I
think
implementers
want
freedom
like.
C
We
would
like
to
be
able
to
schedule
between
things
and
not
rely
on
ordering
guarantees
that
if
we
change
scheduling,
just
a
little
bit
are
gonna
break
everything.
Another
option
that
I've
been
kind
of
just
brainstorming
is
like
you
could
imagine
some
sort
of
abstraction.
Like
a
scheduling
domain,
where
let's
say
you
have
a
page
that
has
a
react.
Scheduler
on
it
and
react
creates
its
own
scheduling
domain
and
within
that
domain,
things
are
ordered
very
specifically
with
with
regard
to
rank
right,
and
then
you
you,
you
pass
the
domain
to
post-task.
C
Let's
say
something:
something
like
that.
I
think
something
like
that
would
work.
It's
just
a
matter
of
you
know.
Is
it
ergonomic?
Is
that
what
we
want
to
do?
But
I
think,
from
our
perspective,
we
need
some
sort
of
isolation
in
order
to
make
something
like
this
work,
which
we're
learning-
and
I
think
the
advantage
of
thinking
about
this
now-
is
that
we
don't.
C
You
know
with
post
task
v
v,
one
like
what
ordering
guarantees
do
we
provide
there
and
is
that
going
to
hurt
us
down
the
line.
So
this
is
one
reason
that
we're
thinking
about
this
kind
of
in
conjunction
and
this,
this
ties
a
bit
into
the
third
party
thing
that
I'll
mention
on
the
next
slide
is
that
with
third
party.
D
C
You
kind
of
want
some
sort
of
isolation
there
as
well,
so
that
you
can,
you
know,
maybe
lower
the
priority
of
things
that
are
in
some
domain.
So
I
I
do
feel
like
some
sort
of
concept
around
declaring
a
domain
or
either
declaring
a
domain
for
yourself
or
for
another
thing,
might
work
here
to
give
the
browser
that
sort
of
separation
it
needs
to
be
able
to
freely
schedule
between
things.
A
C
Either
either
rely
on
the
signal
or
or
it
is
yeah
I
mean,
I
think
we
still
want
some
sort
of
separation,
so
I
mean
you
could
imagine,
there's
a
default
domain
right
and
for
apps
that
don't
need
to
worry
about
this.
You
know
for
for
simple
use
cases.
Then
they
don't
have
to
declare
a
main
domain.
It's
just
when
multiple
things
start
using
it
with
different
ranking
systems
that
are
the
problem.
A
C
So
I
think,
there's
a
little
bit
of
a
you
know
how
worried
would
we
be
about
that
problem?
If
we
did
let
the
default
rank?
Have
you
know
these?
These
guarantees.
C
Or
sorry,
the
default
like
domain,
just
just
no
domain
and
we
implement
rank
like
how
bad
will
that
be
without
having
like
some
sort
of
separation,
some
sort
of
domain
thing.
C
Ideally,
you
know,
since
post-test
re
returns
a
promise
right
like
if
you
have
work
that
is
dependent
on
that
work
finishing
you
could
just
schedule
the
task
when
the
promise
results,
which
is
one
way
to
say
like
okay,
we're
not
gonna,
give
you
any
ordering
guarantees
and
you
need
to
just
rely
on
the
promise
yeah.
I
think
you
know
at
least
this
quarter
with
you
know.
C
I've
shared
this
with
some
some
partners
that
are
interested
in
this
type
of
thing
and
trying
to
get
some
feedback,
and
this
is
where
the
ordering
question
even
kind
of
came
up,
and
I
think,
maybe
soliciting
some
some
things
around
expectations
from
developers
would
be
a
good.
You
know
next
step
here.
C
Okay,
so
yeah
moving
on
so
third-party
script.
I
mentioned
this
a
little
bit
just
just
before
this,
so
our
goal
here
is
that
we
want
to
give
developers
some
sort
of
control
over
when
third-party
stuff
runs
on
the
main
thread.
You
know,
as
cliff
was
saying
in
his
talk
like
this
is
something
that
we've
heard
a
lot
as
well.
That,
like
third
party,
makes
my
site
slow.
So
our
first
step
here
before
we
you
know,
do
any
sort
of
proposal
or
anything
is
okay.
What
does
that
mean
exactly
so?
C
We
we've
been,
you
know,
building
some
some
sample
apps
some
some
demo
sites
and
collecting
traces
looking
at
metrics
to
try
to
understand
a
couple
things
one.
You
know
primarily
what
is
being
done
on
the
main
thread
by
these
third-party
libraries
and
what
sort
of
control
might
we
have
in
you
know,
what's
the
benefit,
if
we
were
to
let's
say
de-prioritize
that
work,
if
we
could
shift
that
to
the
end
past
first-party
stuff,
does
that
help?
Will
that
make
a
difference?
C
Do
we
need
to
delay
it
for
some
amount
of
time
like
how
do
we
kind
of
get
this
out
of
the
way
and
what
sort
of
impact
is
it
having?
So
this
is
still
all
very
you
know
very
early,
very
nasty
in
the
process
here
we
I
I
I'll,
put
this
in
after
the
after
the
fact
I
did
you
know
kind
of
come
up
with
like
a
strawberry
person
proposal
for
something
around
this.
C
This
space,
which
is
very
similar
to
the
domain
idea
that
I
was
just
kind
of
talking
about
this
problem-
comes
up
with
post-task
as
well
right
like
if
you
know
if
a
third-party
library
starts
using
post-task
highest
priority.
All
of
the
time
like
how
do
we
prevent
that
from
happening,
or
how
do
we
mitigate
that?
If
that
does
become
a
problem,
if
that
work
truly
isn't
the
highest,
you
know
priority.
What
can
we
do?
C
You
know
and
we've
we
think
it's
possible
like
if
you
can,
if
you
can
declare
some
sort
of
domain
or
some
sort
of
like
boundary,
which
could
be
the
script
that
you're
you're
importing
and
if
you're
able
to.
If
you're
able
to
associate
that
with
work
that's
being
scheduled,
then
you
do
have
a
chance
of
controlling
some
of
that
work.
C
So
that's
kind
of
the
direction
that
we're
thinking
here-
iframes,
of
course,
also
provide
another
boundary
and
when
they're
for
iframes
that
are
same
process,
then
there
may
be
some
work
that
we
can
do
here.
If
we
get
some
information
from
the
the
web
author
as
far
as
what
the
importance
is
of
the
iframe,
so
I
think
there's
some
definitely
some
stuff
that
we
can
do
here
and
first
steps
are
probably
to
look
at
this.
C
So
I
think
those
those
few
things
are
like
the
immediate
next
directions
that
were
kind
of
already
involved
in,
as
I
mentioned
at
various
early
steps
in
each
of
those
and
the
space
is
very
broad
and
interconnected
and
there's
a
whole
bunch
of
other
stuff
that
that
pops
up
on
our
radar
all
the
time.
So
I'm
just
going
to
kind
of
maybe
quickly
go
through
what
some
of
those
things
are
and
what
we're
thinking
and
you
know
see
if
any
of
it
resonates
with
folks.
C
So
one
one
natural
extension
of
post
task
is
that
in
it
extending
it
to
not
just
tasks
that
developers
are
posting
themselves
but
to
other
asynchronous
things
that
they
don't
have
as
much
control
over
such
as
I
o.
So
you
know
a
couple
of
the
probably
the
most
important
things
I
think
that
have
come
up
so
far
are
indexeddb
and
network
resources.
C
C
You
know
if
we
can
expose
the
task
signal
object
to
other
things
as
well.
You
know,
there's
some
other
things
that
might
actually
pop
out
that
are
really
interesting
as
well.
You
can
imagine,
maybe
even
querying
this
signal
to
understand
whether
or
not
the
transaction
is
ready
or
a
fetch
is
completed.
Something
like
that.
So
this
is
something
that
you
know
we're
not
actively
working
on
right
now,
but
we
are
hearing
from
folks
that
these
are
important
issues.
C
This
comes
up
over
and
over
again
with
network
issue
network
resources,
not
just
for
fetch,
which,
although
fetch,
is
a
really
good
candidate,
because
it
already
you
know,
supports
an
abort
signal.
You
can
imagine
if
we
pass
an
attack
signal.
We
can
make
that
understand
the
importance
of
of
the
priority
on
the
main
thread,
but
we
also
get
you
know
a
lot
of
feedback
from
folks
that
you
know
we
really
wish.
C
We
had
control
over
ordering
of
things
when
they
hit
the
main
thread
like
they
have
some
degree
of
control
using
async
and
defer
on
their
scripts
loading
them
at
various
times
to
get
things
to.
You
know
kind
of
load
in
the
right
order,
but
it
is
a
pain
point
for
multiple
folks
that
they
feel
like
they
could
use
a
bit
more
control
over
how
these
things
are
ordered
on
the
main
thread,
especially
during
loading.
C
So
I
don't
really
have
any
answers
or
any
like
thoughts
on
api
proposals
here,
but
it
seems
like
something
that
we
may
be
able
to
extend.
You
know
the
notion
of
the
the
task
signal
or
something
too.
C
Okay
and
then
kind
of
quickly,
just
a
bunch
of
miscellaneous
things
that
we've
heard
that
that
are
on
our
radar
for
the
space
as
well.
Some
folks,
especially
from
different
various
frameworks,
are
interested
in
extending
post-task
to
microtasks,
like
they
really
like
the
api
shape
and
think
it's
ergonomic
and
would
like
it,
but
they
do
some
scheduling
of
tasks
that
have
to
happen
within
the
context
of
the
current
task.
C
So
there's
demand
for
that.
There's
demand
for
after
task
callbacks
so
like
some,
some
folks
really
want
to
either
either
do
something
or
measure
the
overall
task
length.
But
it's
really
hard
to
do
that.
Like
you,
don't
know
when
all
of
the
micro
tasks
have
finished
so
amp,
for
instance,
has
this
glorious
hack,
where
they
cue,
like
20
micro
tasks,
in
order
to
try
to
get
to
the
end
of
the
micro
task
queue.
Something
like
that.
So
there
could
be.
C
You
know
a
nice
ergonomic
way
to
do
a
callback
after
the
test.
The
full
task
is
completed,
something
else.
That's
bubbled
up,
async
task
graph
tracking.
So
a
task
can
you
know
it
kind
of
gets
down
to
the
notion
of
like
what
is
a
task,
and
a
task
may
may
spawn
multiple
async
things,
and
this
kind
of
creates
this
task
graph
and
folks
would
find
it
useful
to
do
bookkeeping
or
measurement
for
testing
harnesses.
C
And
then
finally,
post
task
and
rendering
this,
I
think,
maybe
touches
a
little
bit
on
michael's
top
earlier
when
we're
talking
about
you,
know
animations
and
drop
frames
from
the
browser's
perspective.
We
don't
always
know
like
when
there
is
contention
how
important
rendering
should
be
you
know
and-
and
I
think,
there's
a
question:
gnome
had
had
taken
a
look
at
the
api
in
context
of
excel
online
and
provided
some
feedback
that,
like
you,
know,
yeah.
C
It
would
be
maybe
really
great
to
have
some
control
over
how
many
of
these
tasks
run
in
between
frames
right
now,
we're
still
just
leaving
it
in
v1
we're
just
leaving
it
up
to
the
the
ua
to
decide
that,
but
maybe
providing
some
sort
of
hint
as
to
how
important
an
animation
or
frame
is
compared
to
other
work
in
times
of
contention
may
be
useful.
So
we
don't
never
really
thought
far
through
this,
but
just
something.
D
Yeah
we
also
talked
about
instead
of
how
many
tasks,
which
could
be
vague,
more
of
a
time
budget
right
right,
right,
yeah,
like
after
a
certain
time,
has
passed
and
that's
a
signal.
A
very
specific
app
could
provide
the
the
schedule
would
yield
to
whatever
needs
to
happen
on
the
rendering
process,
and
that
would
avoid,
I
guess,
response,
input,
delay
and
animation.
D
Smoothness
interruptions,
especially
if
people
are
actually
optimizing
their
app
by
splitting
all
their
long
tasks
to
very
too
short
tasks
and
which
could
lead
to
starvation,
because
a
lot
of
short
tasks
could
accumulate
and
never
yield
or
rarely
yield
to
the
rendering
thread.
And
I
was
able
to
reproduce
this
with
the
with
the
current
implementation
of
the
scheduling
api
by
build
using
very
short
tasks
of
like
10
milliseconds
and
easily
accidentally
blocking
the
render
thread
render
process
for
over
300
milliseconds
every
time
which
would
lead
to
bad
interactivity.
C
We've
made
some
changes
in
chrome
since
then,
like
we've
capped
the
the
delay
that
any
tasks
should
start
rendering
to
about
100
milliseconds,
but
that's
still
only
a
lower
bound
on
on
frame
rate.
I
think
maybe
the
way
that
that
chromium
chooses
to
to
run
the
rendering
steps
are
different
than
other
browsers.
I
see
I
see
differences
across
all
browsers
when
we've
done
testing
on
this.
C
So
having
input,
I
think,
from
developers,
at
least
from
from
our
perspective,
would
be
helpful,
like
we're
always
managing
this
trade-off
between
in
times
where,
where
things
are
really
contentious,
if,
if
you're
rendering
too
frequently,
then
you
can
slow
down
what,
like
you
increase,
the
latency
of
whatever
is
trying
to
happen,
rendering
can
get
more
rendering,
which
slows
down
the
entire
duration
of
whatever
the
thing
is
so
having
some
sort
of
inputs.
Here,
I
think
you
know,
from
from
our
perspective,
could
be
useful.
C
So
yeah,
I
think
that's
for
me.
That's
all
I
had
there's
some
links
here
at
the
end
for
explainers
and
proposals
and
and
things
that
we
have
kind
of
going
on
so
happy
to
take
any
feedback
questions
that
folks
have.
G
I
don't
have
the
option
in
google
here
just
really
quickly
on
the
third
party
partization
stuff
is,
did
you
say
there
was
a
proposal
that
you
had
or
that
still
is
in
pre-proposal
state.
C
I
brainstormed
a
thing
sometime
last
year.
I
think
it's
not
a
formal
proposal,
it's
more
of
a
like
here's,
a
thing
that
I
think
could
work,
especially
for
the
post-test
case,
but
right
now
we
want
to
look
at
the
space
a
bit
more
holistically
and
see.
You
know
that
that
proposal
or
something
in
that
line
like
will
that
work
in
general
or
is
this
only
attacking
a
small
part
of
the
problem?
G
Yeah
I'd
love
to
see
it.
I
think
it's
a
fantastic
idea.
I
think
there's
also,
of
course,
a
thousand
holes
that
people
are
going
to
shoot
through
anything
that
you
put
out
there,
but
I
think
there's
a
lot
of
the
the
question
on
partization
and
is
it
conditional?
Is
it
something
you
know
knowing
the
domains
is
going
to
be
a
really
challenge,
big
challenge
for
developers
when
there's
so
many
different
third-party
domains
that
may
enter
into
a
page
that
they're
not
even
aware
of
yeah
upgrading.
C
H
Yeah,
we
realized
that
we
needed
to
have
more
data
about
what
these
third-party
plugins
were
doing
anyway,
so
we
took
10
popular
third-party
plugins
and
have
stuck
them
in
a
wordpress
instance
and
we're
basically
running
through
and
being
like.
What
all
are
you
doing?
Okay,
what
are
you
doing
during
load?
What
are
you
doing
after
load?
How
are
you
sort
of
scheduling
it
now?
I
mean
no
api
for
that,
but
how?
A
Yeah
just
one
thing
to
bear
in
mind:
there
is
like,
obviously,
the
from
a
security
perspective.
Not
everything
can
be
exposed
even
plain
urls
like
they
will
like.
We
will
need
some
sort
of
an
opt-in
from
the
third
parties
to
expose
some
of
the
information
about
what
they
are
doing
and
what
they're
loading,
especially
when
we're
talking
about
frames.
A
A
C
I
did
go
ahead
and
link
the
early
proposal
I
had
there.
I
mean
the
idea
here
was
essentially
that
developers
could
say
like
they're
loading,
a
script
and
say
this
thing
is
not
that
important
right
like
please
de-prioritize
its
async
work
and
maybe
that
can
propagate
through
frames.
It
creates
in
you
know,
blah
blah
down
the
line.
That's
kind
of
the
rough
idea.
H
Yeah,
I
also
think
surfacing
what
third
parties
are
doing
upward
would
just
put
application
authors
in
the
same
bad
position.
They
are
where
they're
having
to
manage
the
behavior
of
something
that's
mostly
out
of
their
control,
so
I'm
not
sure
surfacing
that
information
would
actually
lead
to
faster
web.
It
would.
A
B
Yeah,
there's
a
there's
a
as
a
run
provider,
there's
a
big
request
from
our
customers
to
get
insights
into
what's
causing
the
pain,
and
you
know
we
would
have
the
opportunity
to
try
to
do
those
sorts
of
jump
through
those
hoops
and
figure
out.
You
know
who
to
attribute
work
towards
yeah.
C
And
you
can
imagine
that
being
incredibly
useful
for
then,
if
there
is
some
sort
of
api
where
they
can
do
some
sort
of
control
like
now
now
it
is
actionable
in
a
way
that
happened
before
yeah
absolutely.
H
Well,
it
sounds
like
we
should
keep
thinking
about
how
to
surface
that
information,
and
maybe
even
do
a
preliminary
chat
with
some
security
folks
to
see
what's
possible.
How
does
that
sound.
I
Yeah,
just
I
just
wanted
to
say
that
there's
also
the
problem
of
when
the
third
party
injects
the
script
in
the
in
the
main
thread,
and
I
think
this
kind
of
proposal
will
just
make
that
much
more
incentivized.
And
I
don't
know
if
we
want
to
incentivize
that
kind
of.
C
So
we
we
were
interested
in
de-prioritizing
things
in
the
mainframe
context,
including
scripts
that
are
injected
by
the
third
party.
I
mean,
I
think,
if
you're
there's
still
always
going
to
be
some
sort
of
work
around,
I'm
sure
to
like
escape
like
whatever
little
like
you
can't
really
sandbox
in
the
same
thread,
but
for
well-meaning
actors.
Anyways
this
something
like
this
may
work,
but
you're
right.
We
will
also
need
to
consider
what
happens
when
people
do
try
to
avoid
this,
and
do
we
make
the
situation
worse
or
not.
A
Yeah,
I
guess
the
nicholas's
point
is
that
we
shouldn't
make
that
descheduling
only
possible
in
the
context
of
frames
and
not
possible
in
the
context
of
the
mainframe.
Because
then
all
the
third
parties
will
just
move
to
the
mainframe
and
we
should
encourage
them
to
be
on.
A
Cool,
so
shall
we
move
on
to
next
subject,
since
we
only
have
20
something
minutes
to
cover
that
so
or
unless
folks
can
stick
around
for
a
few
minutes
after.
I
I
I
What
is
the
time
between
when
the
event
timestamp
occurred,
so
the
user
interacted
with
the
page
and
when
it
begins
to
be
handled
by
the
browser?
And
here
it?
I
guess
it's
important
to
remark
that
it's
begins
and
not
when
it
ends
so
like
just
when
it's
about
to
be
handled.
I
The
first
problem
is
that
it
does
not
capture
the
end-to-end
latency
of
the
user
interaction
because
it
only
captures
from
when
it
began
to
when
it
started
being
processed
by
the
user
agent,
and
the
second
problem
is
that
it
only
measures
the
very
first
user
interaction,
so
that
is
in
particular
bad
for,
for
example,
single
page
apps,
where
the
initial
page
load
is
only
one
and
then
it
can
happen
like
you
can
have
many
user
interactions
after
that,
but
it
it
can
also
be
a
problem
for
any
page
load
where
you
just
look
at
the
first
interaction
and
then
the
metric
disregards
the
rest.
I
I
At
some
point,
the
the
renderer
may
receive
the
input
event,
meaning
the
the
javascript
process
may
be
made
aware
of
the
input
event
and
later
on
in
green.
It
starts
handling
the
input
event.
So
that's
when
it
runs
the
event
handlers
for
that
event,.
I
After
they
are
run,
there
may
be
a
frame
presented
to
the
screen
as
a
result
of
those
event
handlers,
so
that
is
the
first
yellow
star
and
the
the
event
handlers
may
have
posted
some
tasks,
possibly
set
timeout
or
fetch
or
other
work,
which
is
highlighted
in
red.
So
this
is
work
that
is
not
in
the
same
task
as
the
event
handlers,
but
it
is
related
to
the
event.
D
I
Event
handling,
so,
after
all
those
red
tasks
are
completed,
we
can
have
the
final
screen
update,
which
is
the
result
of
what
what
what
the
user
will
consider
the
end
of
the
interaction
which
is
when
the
screen
is
updated.
After
all,
those
red
tasks
are
completed,
so
in
an
ideal
world
we
would
surface
the
full
duration
of
the
event
latency.
I
We
would
determine
this
from
the
user
agent
side.
So
to
that
extent
it
in
some
in
some
ways
it
requires
tracking
causality.
So
basically,
the
event
handlers
triggered
a
set
timeout
or
maybe
they
even
just
wrote
something
to
some
obscure
scheduler,
which
then
would
trigger
the
task
to
run,
and
that
task
may
fetch
something
and
then
the
after
the
fetch
is
completed.
Then
some
other
task
may
run
so
that
all
requires
tracking
causality.
I'm
not
going
to
dig
too
deep
into
that.
I
There
is
a
related
talk
from
patrick
hulse
on
long
tasks
which
touches
on
that
subject,
although
the
tracking
is
done,
the
reverse
way,
so
here
we're
trying
to
track
tasks
in
the
future,
whereas
that
talk
will
be
about
backtracking,
so
tracking,
basically
tasks
in
the
past.
But
I
think
some
of
the
some
of
the
strategies
may
may
be
reusable
for
in
this
context.
I
I
So
one
of
the
problems
with
just
aggregating
is
that
a
single
user
interaction
may
trigger
multiple
events
and
by
events
I
mean
like
javascript
events.
So
as
an
example,
when
the
user
taps
on
the
phone
it
will
trigger
pointer
down,
touch,
start
pointer
up,
touch
and
mouse
down
mouse
up
and
finally
click.
I
I
At
the
same
time,
we
also
want
to
enable
developers
to
keep
track
of
per
event
metrics
such
as
duration
of
the
event,
handlers
and
event
queuing
times,
which
is
like
first
input
delay,
but
we
want
to
enable
developers
to
be
able
to
track
metrics
about
user
interactions
themselves
so,
for
example,
end-to-end
latency,
and
here
we
could
just
consider
the
first
yellow
star
just
for
the
purpose
of
the
talk,
since
we're
not
going
to
talk
about
heuristics
for
tracking
the
rest,
so
this
will
basically
be
the
paint
after
event,
handlers
run,
but
we
wanted
for
the
full
user
interaction.
I
So
what
does
that
even
mean
what
I
would
propose
to
enable
tracking?
This
is
adding
an
interaction
id
or
something
along
those
lines
to
the
current
performance
event.
Timing
entry.
I
I
I
I
So
here
you
have
the
various
javascript
events
pointed
down
and
so
on,
and
they
have
different
timestamps,
even
though
it's
the
same
user
interaction,
for
instance,
because
the
pointer
app
occurs
later,
and
I
think
the
click
receives
that
timestamp,
I'm
not
sure
if
it's
guaranteed
but
and
then
we
have
assuming
they
all
have
handlers.
We
have
like
some
handling
durations,
which
is
captured
by
the
time
between
the
green
and
the
blue,
and,
of
course,
they
are
handler
at
different
points
in
time,
and
there
is
also
a
next
paint.
I
After
the
event,
handlers
have
run
which
aims
to
capture.
This
is
the
update
for
for
the
event,
although,
as
I
said,
it's
not
perfect
for
the
reasons
I
mentioned
before.
I
I
I
should
note
this
is
potentially
a
problem
if
you
receive
entries
for
the
same
interaction
in
different
callbacks,
so
something
to
keep
in
mind.
This
is
a
little
simplistic,
but
assuming
you
haven't
processed
it,
then
you
mark
it
as
processed
and
then
you
go
over
the
entries
that
have
that
interaction
id.
So
that
is
the
method
process.
Interaction.
I
So
that
is
one
way
to
do
it.
Some
alternatives
considered
one
would
be
another
interactions
api,
but
this
would
require
yet
another
api
and
we
feel,
like
ideally
we'd
like
to
have
only
one
for
capturing
events.
Slash
interactions
instead
of
having
too
many
apis.
I
But
obviously
that
can
be
flawed
because,
for
instance,
if
the
pointer
down
is
the
one
that
is
slow,
then
your
pointer
up
might
occur
way
later,
and
so
the
heuristic
will
basically
be
hard
to
get
right.
So
we
think
it's
important
to
enable
developers
to
accurately
know
which
are
the
events
that
correspond
to
the
same
interaction,
and
that
is
it.
I
So,
as
I
mentioned,
this
is
basically
pretty
early
stages,
like
I
just
thought
about
it
recently,
but
I
wanted
to
present
this
so
that
others
are
aware
of
the
things
we're
thinking
about
in
chrome,
speed,
metrics
regarding
responsiveness
and
acknowledge
the
fact
that
fit
is
not
an
ideal
metric
to
put
it
lightly
and
present
to
you
the
two
core
issues
that
we
are
trying
to
reason
about,
which
again
are
trying
to
measure
the
end-to-end
latency,
as
well
as
trying
to
aggregate
accurately
across
user
interactions,
as
opposed
to
raw
javascript
events.
D
D
What
I
did
try
to
actually
address
this
exact
problem
with
the
existing
api
recently,
and
I
want
to
hear
what
you
think
if
it
makes
sense
and
whether
this
api
would
simplify
my
attempt
and
what
I
tried
is
to
actually
use
the
event
timing
api
to
detect
the
when
the
event
occurred,
and
I
did
not
address
the
aggregate
problem.
Just
let's
assume
there
is
only
one
event
like
click
and
to
determine
the
next
frame
just
combine
that
with
the
element
paint
timing
by
injecting
some
image
to
the
element.
D
I
So
you
you
mentioned,
you
add
an
image
to
the
in
the
event
handler
and
then
use
element
timing
on
top
of
that.
So
since.
D
The
event
handler
does
something
changes,
something
on
the
on
the
dom
right
or
some
style,
or
something
like
that.
I
want
to
measure
when
it
appeared
to
the
user
and
since
element
timing
supports
at
least
at
the
moment,
mostly
image
images
or
image.
Like
elements,
I
used
an
image
to
measure
the
element,
paint
timing
to
determine
the
interacting
end.
I
Regarding
that,
I
wonder
how
different
that
is
from
the
duration
value
that
is
already
available
in
event,
timing
itself,
so
for
for
clarity,
the
first
yellow
star
would
be
already
available.
It
would
be
the
the
duration
attribute
that
captures
from
the
timestamp
to
the
next
frame
after
the
handlers
have
run.
D
D
No,
I
haven't
so
you're
saying
using
the
so
you're
saying
the
element.
Timing
also
addresses
that
which.
A
D
A
I
D
Oh,
I
see
I
see
okay,
so
so
the
problem,
I
guess,
is
that
it's
not
guaranteed
that
my
paint
would
be
on
next
frame
like
you
present
here,
it
could
happen
after
some
other
tasks
and
therefore
I
wanted
to
have
more
explicit
control
on
when
I'm
injecting
the
the
element,
pain,
timing,.
A
I
A
No
so
so
I
think
this
like
knowing
what
you're
describing,
I
think,
makes
sense
in
the
context
of
you
know
a
specific
element
that
you
want
to
measure.
This
is
at
least
my
understanding.
What
element
timing
is
for,
and
I
think
we
will
talk
more
about
various
task
tracking.
That
is,
you
know
that
will
enable
a
generic
solution
for
that
in
the
like
potential
in
the
context
of
a
long
task
attribution,
but
maybe
we
can
bring
that
back.
A
The
discussion
to
the
coalescing
of
different
events
that
are
related
to
a
single
user
interaction
is
this
something
that
you
ran
into?
Is
this
something
that
you
are
concerned
with.
D
To
address
that
as
well,
we
haven't
done
work
on
on
solving
that
problem
and
it
seems
like
an
interesting
proposal.
D
And
I
mean
the
the
example
that
nicholas
gave
in
terms
of
the
code
to
do
doing.
The
processing
seems
simple
enough
so
makes
sense.
A
B
For
impulses,
interaction,
tracking
the
main
thing
that
we're
tracking
today
is
via
for
simple
delay
and
similar
polyfill
for
other
browsers.
We
do
see
a
lot
of
value
in
tracking,
not
only
the
event
processing
time,
but
also
asynchronous
tasks
that
come
from
it
as
well.
So,
like
this
diagram
makes
me
happy.
It's
like
this
is
what
we
have
some
customers,
especially
with
single
page
apps
and
other
things
that
are
highly
interactive
or
highly
dynamic.
B
G
I
agree
from
the
speaker
side
on
lux:
we
we're
tracking
fed
as
well.
I
think
that
the
only
thing
I'd
add
to
that
is
is
with
attribution.
This
is
really
helpful.
I
think-
and
I
am
super
excited
to
see
it.
We
started
tracking
other
things
with
with
input
like
when
the
user
inputs
with
the
page.
You
know
long
after
that
happens
and
we're
super
excited
about
it.
But,
to
be
honest,
I
don't
know
that
it's
really
helped
our
customers
do
a
whole
lot.
G
You
know
what
it
because
applications
just
vary
in
terms
of
when
you're
going
to
interact
with
it
and
what's
sort
of
driving
the
interaction
that
sort
of
thing.
So
I'm
definitely
keen
to
get
more
timing
around
the
actual
processing
and
event
handling.
I
Right
so
the
event
handler
duration,
you
can
get
from
event
timing
by
the
way
right.
D
J
J
Yeah
that
one,
so
when
you
have
the
staggered
events,
do
we
want
the
start
of
the
earliest
event
and
the
render
of
the
latest
event?
Or
I
mean
maybe
my
javascript's,
not
just
not
good
enough,
but
it
feels
like
this
is
actually
just
getting
the
longest
duration
and
it's
not
spanning
the
multiple
events.
I
I
Maybe
there
is
something
different
that
is
more
valuable,
but
this
was
just
an
example
of
something
you
could
measure,
but
yeah
I'm
open
to
ideas
about
what
exactly
we
should
be
measuring
in
terms
of
a
single
user
interaction
like
how
do
we
properly
aggregate
all
of
those
events
corresponding
to
the
same
interaction,
and
if
anyone
has
any
thoughts
or
great
ideas
on
how
to
do
that,
you
can
always
open
an
issue
on
the
wicg
for
event.
Timing.
F
J
I
guess,
if
you
go
back
like
two
or
three
slides
to
where
you
have
the
staggered
events
there,
where
pointer
down,
has
a
different
start
time
than
click.
For
example,
would
we
want
the
duration
to
be
the
time
from
the
start
of
pointer
down
until
the
rendered
frame
of
click
was
what
I
was
sort
of
asking
where
you
need.
I
The
answer
is
yes,
because
if
you
think
of
what
the
user
was
doing,
they
started
clicking
with
pointer
down,
even
though
the
click
was
only
generated.
As
michael
mentioned,
it's
synthetic
right
generated
by
the
browser
later
we,
what
we
really
care
about
is
when
the
user
started,
signaling
that
it
wants
to
do
something
until
that
something
is
completed
which
may
or
may
not
be
the
paint
after
the
click
event.
J
I
Yeah,
I'm
maybe
I
should
clarify,
though,
that
currently
we
surface
events
after
a
certain
duration
threshold,
so
that
makes
tracking
the
interaction.
Ids
trickier,
if
we
say
surfaced
all
events
all
the
time,
then
you
could
idea
yeah.
You
would
have
all
the
information
to
do
it,
but
unfortunately
that
would
be
too
many
events.
I
So
what
we
do
is
we
surface
the
slow
ones
and
you
can
modify
the
threshold
but
not
set
it
to
zero.
So
from
that
perspective
it
would
be
trickier,
like
you
could
potentially
come
into
problems
trying
to
do
that
manually.
K
The
pointer
down
might
not
result
in
a
click,
and
then
you
could
have
a
click
that's
produced
by
something
else,
and
so
the
id
lets
you
associate
those
it's
not
100
clear
to
me
that
you
want
to
associate
those
necessarily
like
do
you
want
to
include
the
duration
that
the
user
held
their
finger
to
the
screen
in
your
performance
metric?
Maybe
you
do
in
some
cases,
you
probably
don't
in
others,
there's
probably
other
use
cases
for
being
able
to
associate
those
events
as
well.
I
Right
yeah,
a
long
tap
is
unclear
in
terms
of
what
you
would
do
to
measure
the
performance
of
that,
but
at
least
having
the
interaction
id
would
let
you
know
that
it
was
a
long
tap
because
you,
then
you
can
well
actually
does
that.
Let
you
know
I
don't
know.
If
there's
a
this
is
there's
a
metric
for
how
long
the
finger
was
in
the
screen
like
I
don't
know
if
the
event
surfaced
that
no
idea
so.
E
D
I
Right
that
oh
you're,
immediate,
I
don't
know
if
you're
still.
D
I
Sorry
I
mean
yeah,
that's
it
that's
a
good
question.
We
try
to
surface
the
discrete
events
in
event,
timing,
but
I
think
it's
a
good
question
for
things
like
drag.
How
would
you
define
the
user
interaction
and
so.
D
D
Yeah
I
mean
I,
I
guess
sometimes
what
you
do
care
about
is
the
pointer
up
event,
not
the
pointer
down
right,
but
I
guess
in
that
case
this
api,
since
you
have
the
interaction
id,
it
already
addresses
that,
because
you
could
just
just
just
aggregate
the
pointer
up
instead
of
the
and
exclude
the
the
events
you
don't
care
about.
I
A
Okay,
so
yeah,
I
think
we
can
wrap
up
feedback
welcome
yeah,
especially
from
folks
playing
around
with
event
timing,
if,
like
yeah,
anyone
dealing
with
metrics,
if
you
haven't
played
around
with
the
band
timing,
please
do
and
provide
feedback
on
the
on
the
ycg
repo
and,
if
you're
running
into
those
kinds
of
problems,
yeah
feedback
would
be
highly
welcome.
And
with
that
I
think
we
wrapped
up
our
first
day
and
if
there's
nothing
else,
we'll
see
you
all
tomorrow.