►
From YouTube: WebPerfWG Triage call - March 29th 2019
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
A
A
A
Yeah
so
I
will
like
we
haven't
yet
run
this
by,
like
my
other
folks,
so
yeah
I
will
send
an
email
to
the
list,
basically
asking
for
those
like
potential
dates
and
I
mean
it
works
for
me
if
it's
somewhere
close
by
to
that
week.
But
if
it's,
you
know
a
few
weeks
after
that,
I
can
go
back
and
forth.
So
yeah.
G
A
D
A
D
A
C
I
believe
that
change
would
only
be
changing
the
ideal
because
observe
already
throws
an
error
if
two
of
its
met,
if
two
of
the
members
are
both
omitted
with
those
being
the
entry
types
member
which
should
give
you
the
array
of
entry,
types
and
type
member
which
you
should
use
for
a
single
entry
type,
so
so
I
believe
the
issue
can
be
solved
by
just
adding
that
optional
in
the
ideal.
So
that's
we
are
basically.
H
C
H
C
H
H
I
B
C
The
other
two
issues
are
related:
they
are
about
supported
entry
types.
The
first
issue,
117,
is
saying
that
we
should
cash
the
frozen
array
instead
of
returning
a
newly
built
frozen
array.
Every
time
the
attribute
Gator
is
called
and
the
solution
is
to
I
think
the
solution
is
to
cache
the
frozen
or
a
pair
environments
of
her
window
or
worker
I
sent
up
here
for
it.
But
apparently
I
may
have
gone
in
the
wording
wrong.
So
I'll
need
someone
to
help
me
with
that.
C
C
J
E
E
C
Is
about
changing
the
way
you
the
attribute?
Gator
is
defined
so
right
now
in
in
the
specification,
it
just
says,
return
a
copy
of
the
list
of
supported
entry
types.
But
since
it's
an
attribute
gather
and
nothing
has
changed,
it
should
return
the
same
object
every
time.
So,
if
you
call
it
twice,
it
should
return
the
same
object.
That's
what
I'm
about
yeah.
C
Entry
types
right,
no,
no,
no
same
object,
so
yeah
same
object.
We
will
add
same
object,
but
that's
not
the
problem
and
apparently
same
object
does
not
have
any
guarantees
right
now,
so
I'm
definitely
adding
same
objects,
but
that's
not
the
main
problem.
The
main
problem
is
simply:
we
don't
want
to
return
a
copy.
C
B
E
E
It
needs
to
be
that,
like,
if
there's
a
single
object
associated
with
each
interface,
that
we
will
return
to
just
remove
the
word.
Cached
yeah
just
does
carry
over
cat
yeah
yeah
I
understand
that's
how
like
some
browsers,
you
may
implement
it
like
the
such
an
implementation
details
shouldn't
creep
in
the
specification
right
like
it.
C
A
So
really,
if
I
understand
it
correctly,
what
you're
saying
is
that
we
should
say
that
the
object
is
like
we
have
that
object
that
contains
that
list.
It's
tied
to
the
environment
settings
object,
probably,
and
then
we
return
that
object
directly,
rather
than
return
a
cached
copy
of
it.
Is
that
what
you.
E
A
C
A
C
So
that
PR
should
also
help
in
fixing
to
the
next
issue,
which
is
about
being
context
aware,
because
since
we
have
one
frozen
or
rape
the
constants
quick
worker,
then
that
would
make
it
easier
for
other
specification
to
specify
the
contents
of
each
frozen
array
depending
on
context.
Okay.
So
that
should
also
have
fixed
that
issue
itself.
Yeah.
A
A
A
J
A
G
A
H
H
K
D
A
A
A
E
I
mention
one
thing:
I
just
noticed
in
a
performance
timeline
about
the
issue
of
support
at
entry
types,
I
think
I
just
realized
that
current
PR
says
read
about
global
project,
but
without
specifying
which
will
pick
the
one
object.
So
I
think
we
have
to
specify
that,
like
you
can't
like,
when
you
say
Globovision,
we
have
to
specify
global
check
the
what
it's
unclear
right
like
if
you
in
general
I,
think
with
your
calling
star
performance
timeline
functions.
E
A
C
E
A
A
A
A
E
A
I
agree,
or
so
so
I
think
this
is
unit
formation.
I,
think
that
the
server
can
surface
it
now
with
server
timing,
if
they
wish
to
do
that,
if
they
don't
wish
to
do
that,
I,
don't
think
that
there
is
currently
a
way
to
get
that
all
right,
so
it
seems
like
so
I,
don't
know
if
we
want
to
do
this
or
not,
but
I
think
that
we
can
easily
postpone
this
to
like
this
is
not
a
blocking
issue
for
l2
I
agree.
E
A
A
A
A
A
You
describe
a
scenario
there
so
currently
for
cross-origin.
If
we
have
a
now
course
across
origins
stylesheet.
That
is
then
fetching
some
resources
we're
supposed
to
not
expose
their
URLs
as
part
of
resource
timing,
and
your
describe
is
describing
a
scenario
where
we
have
stylesheet
a
downloading
stylesheet
b,
which
is
then
downloading
a
sub
sub
resource
and
yours,
basically,
it's
not
clear
if
c
should
or
shouldn't
be
exposed.
A
E
C
A
A
So
right
now
timing,
a
lot
of
origin.
If
you
go
cross
origin
and
then
go
back
to
same
origin,
we
don't
require
towel
on
the
same
origin
in
order
to
expose
the
resource.
But
here
it's
a
slightly
different
case
and
yeah
I
agree
that
it
can
yeah.
If
we
will
show
a
style
like
resource
C,
then
that
can
expose
things
about
what
style
a
is
which
is
theoretically.
J
C
C
L
G
A
D
A
G
E
Yeah,
sorry,
some
are
tricky
cases
if
the
same
resources,
then
fetched
by
same
origin,
no
course
cross
origin
resource
again.
In
that
case,
the
browser
I
believe
many
kids
like
currently
do
not
reflect
the
resource,
but
because
of
timing
at
which
it
was
fetched
right,
it
could
be
exposed
and
it
could
expose
the
fact
that
cross
urging
this
was
loaded.
The
resource
and
I
don't
know
how
to
result
like
I'm
yeah.
E
A
D
G
A
J
A
D
D
C
A
A
A
D
A
A
E
E
E
A
I
A
This
is
something
that
is,
you
know
well
defined
in
Korres,
then
you
can
probably
quit
like.
Do
a
quick,
follow
and
follow
the
same
logic.
If
not,
then
it's
probably
from
my
perspective
and
l3
issue
even
like,
because
it
sounds
like
something
that
will
require
fetch
integration
as
well
as
the
finding
it
in
touch.
E
A
D
A
One,
so
if
we
just
like
one
minute
before
we
for
like
for
resource
timing,
there
is
one
extra
test
that
is
pending
related
to
tau.
It
is
testing
the
current
behavior
as
defined
and
not
the
behavior.
That
Anna
would
like
it
to
be
the,
which
is
the
behavior
that
mirrors
course.
But
if
someone
could
review
that
test
and
we
could
land
it,
that
would
be
awesome
here.
A
A
I
L
C
A
A
Think
they're
ours
like
we're
missing
some
language
there
so
for
workers,
start
I,
I'm,
pretty
sure
we're
not
saying
that
it's
gated
by
timing
law
origins.
So
we
should
change
the
spec
wording
as
well
as
a
test,
but
the
spec
wording
change
is
the
easy
part.
So
the
test
is
the
part.
That's
a
bit
more
complex
workers
start
should
be
clearly
the
fun
as
applicable
to
the
left
service
worker.
A
A
And
then
we
have
Boris's
issue
about
applying
timing
allowed
check
to
a
document
where
he
is
correct
that
we
have
refactored.
The
timing
allowed
check-in
resource
timing
to
accept
a
request
rather
than
a
document.
But
we
haven't
updated
the
navigation
timing
piece,
which
is
another
data
point
as
to
why
we
probably
want
to.