►
From YouTube: WebPerfWG call - April 9th 2020
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
A
Agenda
document
that
was
shared
out
there's
a
list
of
issues
that
we're
gonna
go
through.
There's
quite
a
big
list.
I,
don't
know
how
many
will
actually
get
through
today,
but
might
as
well
just
go
steady
on
through
them.
If
we
can,
the
first
thing
that
we're
gonna
start
out
with
was
long
tasks
and
we're
actually
gonna
start
out
with
long
tasks
issued
number
75,
I
think
today.
So
this
one
is
talking
about
tap
level
browser
browsing
contacts,
coping
it
was
opened
by
a
last
November
and
I
know:
Nicolas
you've
had
some
feedback
into
it.
A
It
did
sound
like,
like
I,
said
a
high
level.
The
question
is:
why
are
we
using
template
or
browsing
contacts,
as
opposed
to
the
document
that
is
actually
executing
the
tasks
and
Nicolas
is
on
the
like?
After
some
back-and-forth,
we
were
thinking
that
there
was
an
easy
change
to
the
spec,
possibly
to
update,
which
document
we're
talking
about
I,
don't
know
if
there's
any
more
discussion
that
need
to
be
had
there
or
if
it's
just
a
matter
of
actually
shooting
those
updates
into
the
spec.
When
we
get
time.
E
E
A
A
You
have
a
quick
question
for
labeling
issues
and
stuff
like
this
that
we've,
you
know
we've.
We
think
the
discussion
is
understood,
but
we
just
need
to
make
edits
or
there's,
like
particular
labels,
that
we
would
use
on
an
issue
to
market
as
like,
hey,
we
just
need
to
actually
get
the
time
to
do
this
kind
of
work.
F
D
D
F
F
D
G
F
B
D
A
D
D
D
D
F
So
so
document
is
a
single
process
at
the
released,
but
maybe
what
Anna
was
referring
to
was
some
place
in
the
teardown
or
like
during
the
vacation,
where
you
have
a
browsing
context
that
still
holds
the
previous
document
in
one
process,
then
the
future
document
in
another
prime.
Maybe
that
was
one
like
something
that
Anna
referred
to.
D
A
D
G
D
So
so
in
the
example.
If
you
have
two
origins
and
in
the
same
process,
then
all
of
the
long
tasks
are
reported
to
both
of
the
origins.
The
the
difference,
of
course,
is
of
the
attribution
of
the
long
task
is
reported.
So
when
there
are
security
concerns
with
saying
where
it's
coming
from
I
think
the
attribution
just
says
it's
unknown.
So
you
don't
know
if
the
long
task
comes
from
the
browser
if
it
comes
from
the
coarser
agent
frame.
That
makes
sense
so
now.
D
F
Basically,
today,
like
a
concrete
examples,
you
can
have
you
know
multiple
sites
like
multiple
origins,
on
the
same
side.
So,
let's
say
google.com
and
Google
Docs
both
run
in
the
same
process.
One
of
them
has
many
long
tasks.
What
but
those
long
tasks
influence
both
right
now
they
are
reported
to
both
I,
don't
know
what
we're
doing
like
I'm
guessing
we're
not
doing
the
same
kind
of
reporting
on
Android
wear
different
sites
and,
being
you
can
find
themselves
a
process
and.
F
F
F
Either
cross
origin
or
cross
side
depending
on
the
definition
I,
don't
remember
if
they
have
a
cross-site
bit,
but
basically
you
can
say
that
you
know
a
context
that
cannot
load
anything
that
it
not.
That
is
not
explicitly
opting
out
to
be
embedded,
and
that
is
something
that
there
are
people
planning
to,
for
example,
enable
shared
array
buffers
based
on
that
and
other
powerful
features
that
enable.
F
E
D
F
D
Okay,
so
I
guess
my
suggestion
would
be
to
just
go
ahead
with
what
I
suggested
back
then,
which
is
to
replace
the
browsing
contacts
with
Doc's,
which
is
the
documents
that
are
affected,
and
then
we
need
to
change
the
report
from
tasks
algorithm
to
simplify
it,
because
right
now
we're
getting
all
the
browsing
contexts
in
that
algorithm.
So
if
it
just
receives
the
document
already,
then
there's
no
need
to
do
that.
D
D
A
A
D
We
start
the
task
and
then
like
after
that
work
that
you
were
waiting
for
is
them
and
then
just
have
n
time
would
technically
be
super
inflated
because
you
just
look
at
the
start
and
the
end
time
for,
of
course,
it's
gonna
count
all
the
tasks
that
were
running
between
what
I'm
saying
is
that
that's
a
bug
in
the
HTML
spec
there
shouldn't
be
any
task
oriented
it
should
just
be.
It
should
really
be
defined
as
separate
tasks,
but
that's
a
whole
other
issue.
I
guess
and.
A
D
D
B
D
D
This
means
your
tasks.
Your
task
length
would
be
inflated
if
you
have
an
alert.
Yes
wait
for
the
user
to
dismiss
the
alert
in
order
to
continue
your
task
like
I,
guess,
I
had
the
question
thereof.
If
you
had
other
work
pending,
we
didn't
be
able
to
execute
while
the
alert
is
showing
to
the
user.
No,
no.
D
If,
if
the
work
is
blocked,
if
other
work
is
blocked
from
executing
well,
the
alert
is
showing
to
users
and
I
think
it's
reasonable
to
just
count
all
of
that
as
part
of
the
task
length,
because
the
intent
is
to
capture
when
the
process
is
busy
right
and
then
cannot
respond
to
user
input
or
to
new
work
that
is
being
issued.
So
if,
during
an
alert,
there's
no
possibility
to
the
other
work,
then
it
seems
reasonable
to
just
count
that,
as
part
of
the
test
links
is
an.
A
D
A
F
D
Proposal
would
be
to
wait
until
we
have
to
again
well
I
know:
I
always
hunt
everything
to
that,
but
until
we
have
such
as
sampling
profiler,
because
that
will
also
solve
the
use
case,
presumably
because
when
you
were
learning,
presumably
the
alert
will
be
in
the
call
call
stack
right.
In
that
case,
you
would
easily
be
able
to
determine
the
tests
that
are
caused
by
something
like
that.
Like.
D
F
A
Think
we
got
some
good
notes
for
that.
So
the
last
issue
for
long
tasks
in
particular
that
I
had
acute
up
today.
I
know
reduce
guy,
had
opened
it,
but
I,
don't
think
he's
actually
on
the
chat.
I
think
he
wasn't
able
to
make
it
so
we
could
potentially
skip
it
but
I.
It
says
issue
number
80,
which
is
that
the
combination
of
paint,
timing
and
long
tasks
can
expose
precise
paint
timing,
and
it
was
an
issue
I
think
originally
opened
in
the
paint,
timing,
repo
and
then
moved
to
the
long
task.
A
D
D
Perhaps
we
should
just
remove
one
tasks
from
there
altogether
and
in
particular
that
that's
also
concerned,
because
we
won't
be
having
that
at
all
right
now,
we
report
to
clarify
report
long
tasks
after
the
task
ends
in
the
event
loop,
and
then
we
bought
again
for
the
update
the
rendering
step.
So
this
issue
is
regarding
that
second
time
we
would
report
which
we
don't
really
implement
in
chrome,
at
least
and
I
think
is
probably
not.
D
F
F
F
So
the
issue
here
is
related
to
rendering
long
tasks
which
chrome
doesn't
currently
expose,
and
what
Nicolas
was
saying
is
that
it
feels
like
something
that
should
be
exposed
in
a
different
API.
So,
for
example,
the
frame
timing,
API
and
not
a
part
of
long
tasks
and
simply
removing
that
from
the
spec
would
resolve
this
issue.
F
G
D
F
Mean
basically
issue
is
that
paying
timing
as
specified
exposes
a
start
time
for
the
update,
the
rendering
step
and
long
casts
rendering
long
tests
as
specified,
but
not
as
implemented,
would
expose
at
the
endpoint
of
that
yeah.
So
that
exposes
at
precise
time
of
a
play,
the
renderings
yeah,
which
has
potential
sensitivity.
F
D
F
F
D
So
now
I
would
suggest
removing
the
long
tasks
since
we
don't
really
implement
them
or
have
any
plan
to
implement
them
in
the
near
future.
Anyway,
if
we
decide
oh
this
actually
makes
sense.
Then
we
can
just
react
and
later,
but
at
this
point
it
seems
to
be
causing
more
confusion
than
anything
else.
The
power
just
remove
it,
and
that
was
all
fascia,
since
we
won't
have
those
time
stamps
that.
F
A
A
C
D
D
So
I
wanted
to
discuss
that
and
say
I
probably
would
prefer
if
we
instead
go
with
a
more
holistic
solution
which
doesn't
treat
paint
timing
as
so
special
and
the
options
are
age.
Visibility
which
requires
some
work,
but
will
let
you
have
like
the
full
history
of
the
visibility
of
a
document
or
the
other
option
would
be
just
had
a
boolean
or
yeah
like
a
flag
in
the
performance
entry
saying
that
this
was
back
rounded
before
if
the
entry
was
created.
A
A
A
And
that
one
sounds
best
to
me,
because
that
can
I
also
kind
of
just
give
each
consumer
of
the
data,
the
choice
and
whether
or
not
they
want
to
take
action
based
on
based
on
that,
and
it
also
kind
of
also
puts
kind
of
front
and
center
within,
like
we
were
to
put
this
information
down
the
performance
entry
itself.
It
could
actually
also
highlight
to
the
consumer
of
this
data
that
they
may
want
to
know.
A
F
F
C
D
A
The
other
proposal
that
Nicholas
mentioned
is
making
page
visibility
more
consumable
in
especially
in
cases
where,
like
analytic,
scripts
load
later
and
the
page,
and
don't
have
full
visibility
to
the
past
and
like
I
like
that
option
as
well
cuz,
you
know
having
that
information
about
the
pages.
Full
lifecycle
of
its
visibility
states
would
be
very
helpful
for
not
only
this,
but
for
other
things
as
well,
but
I
think
that
would
also
require
a
little
bit
more
work
to
think
through,
but
I
think
that
would
be
the
kind
of
the
alternate
proposal.
A
H
Page
visibility,
there's
at
the
moment
that
takes
a
bit
of
work
to
keep
track
of
that
visibility.
State
we're
gonna
be
conceivable
to
just
have
a
boolean
on
the
window.
That
tells
you
it's
been
been
grounded
at
some
point
before
because
Rita's
that's
a
use
case.
We're
talking
about
here,
and
you
want
that
information
potentially
late.
If
your
JavaScript
doesn't
get
too
little
early
and
you
might
not
get
a
chance
to
set
up
the
observer
and
get
you
know,
read.
H
I
mean
I
I
still
think
that
the
flag
on
each
entry
is
the
best
way
to
go
and
just
keeping
it
to
visibility,
because
that's
the
simplest
way
to
reason
about
it.
You
know
whether
visibility
will
have
an
impact
on
throttling
in
the
future.
It
means
to
be
known,
but
just
keep
it
simple.
You
know
I
strongly
agree
with
that.
D
D
F
D
H
A
Well,
the
the
boolean
that
we're
talking
about
that
would
be
on
the
interview
that
would
be
with
that
be
a
this
has
ever
the
page
has
ever
been
hidden
or
would
it
be
the
this
entry
was
fired
while
the
page
was
hidden?
If
it's
the
first
was
ever,
my
concern
would
be
if
we
start
looking
into
things
in
the
future.
Like
you
know
single
page
app
interactions
and
stuff,
you
don't
necessarily
want
a
boolean
to
live
forever.
I
was
like
this
page:
I
went
that
was
hidden
and
now
you're.
A
Bit:
okay,
we're
cedeƱo,
whereas
if
you
had
like
this
log,
obviously
of
state
transitions,
then
you
could
look
to
see
which
ones
were
relevant
for
you
within
the
time
frame
that
you
cared
about.
You
know
the
last
three
seconds
before
your
interaction
happened
on
the
page
or
something
like
that.
Just
gives
you
a
little
more
flexibility,
I
think.
In
that
case,
you.
A
A
coach
I
think
it'd
be
worthwhile
to
review
where
the
discussion
was
left,
with
page
visibility,
at
least
to
see
if
there
were
any
other
major
concerns
with
having
an
observer
for
page
visibility
that
we
had
discussed.
If
it
looks
like
we
last
talked
about
it
in
2017,
so
I'm
sure
things
have
changed.
Oh
there's.
A
Fair
enough,
why
don't
we
try
to
pick
up
that
at
least
that
peach
visibility
issue,
maybe
for
the
next
discussion
and
make
sure
yeah
make
sure
there's
nothing
wrong
with
it,
and
then
we
can
pounder
it
a
little
as
well
from
it
sounds
like
it
sounds
like
there
are.
Developers
could
want
to
either
way
so
I'm,
not
sure.
If.