►
From YouTube: WebPerfWG call 2021 06 10
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
yeah
this,
today's
meeting
is
being
recorded
and
we'll
be
posting
online
and
take
it
away.
Nick.
B
Thanks
first,
some
administrative
business.
The
next
meeting,
we're
planning
on
is
two
weeks
from
today
june
24th,
at
the
same
time
as
usual,
any
concerns
or
objections
to
that
all
right.
We
will
plan
on
that
on
the
agenda.
Today
we
have
a
mixture
of
basically
issue
triage
for
all
the
different
repos.
We
don't
have
any
presentations
that
I'm
aware
of
so
my
plan
was
just
to
kind
of
go
down
to
the
list
and
do
what
we
can
see
as
far
as
we
can
get.
B
We
have
some
things
for
all
this:
all
the
repos
and
specs.
In
general,
we
have
some
resource
timing
issues,
fetch
issues
and
some
other
miscellaneous
ones
as
well.
Why
don't
we
just
start
going
down
the
list.
Yo?
Are
you
planning
on
trying
to
scribe
for
some
of
this
yeah?
Thank
you
and
I'm
not
sure.
I
I
believe
at
some
point
I'll,
probably
be
asking
you
about
some
of
these
issues,
so
I
will
try
to
hop
in
then
if
anybody
else
is
interested
in
providing
backup
that
would
be
appreciated
as
well.
B
The
minutes
is
linked
to
from
the
main
agenda
today,
and
I
will
actually
just
post
that
into
our
chat
channel
as
well.
B
Okay,
let's
start
with
the
first
one,
which
is
in
our
web
performance
repo.
So
it's
kind
of
our
uber
repo
that
talks
about
all
the
things
that
we're
doing
issue
number
36
opened
up
by
marcos
and
he's
basically
suggesting
that
we
try
to
do
a
pull
request
template
for
that
repo,
I'm
seeing,
but
probably
for
all
of
the
different
repos
he
did
actually
have
a
suggested.
I
think
pull
request
template
in
hr
time
number,
121
and
you're
welcome
to
take
a
look
at
the
change
there.
B
The
change
list,
it's
basically
just
a
single
markdown
file
with
some
fill
in
the
blank
areas
for
people
that
want
to
open
a
poll
request,
maybe
might
be
worthwhile
to
present.
B
B
Okay,
so
this
is
the
suggested
pull
request,
template
that
we
can
obviously
tweak
to
our
needs,
but
kind
of
gives
us
a
starting
point.
Basically
fill
out
details
close
any
issues
mark
whether
there
are
any
implementation
commitments
for
this
ongoing
tasks
and
then
how
to
title
it
as
well.
So,
basically
kind
of
gives
you
a
starting
point.
If
you
are
going
to
open
up
a
pull
request.
B
B
Yeah,
so
the
suggestion
is
that
the
commits
are
squashed
with
one
of
the
following
as
a
message.
Prefix,
and
maybe
some
of
the
sections
above
are
not
necessary.
If
you
are
only
doing
an
editorial
or
something
like
that,
so
we
probably
make
that
a
little
bit
clearer.
Where
you
know
implementation
commitments
is
not
necessary
if
you're
just
doing
an
editorial
or
something
or
chore.
A
Yeah,
I
think
that
the
like,
I
think
we
should
change
the
like
breaking
change
to
just
change
and
then
maybe
have
a
different
field
for
like
backward
compat
risky
change
that
will
need
further
like
more
justifications
and
more
data
behind
it.
C
Sense,
sorry,
just
another
question:
what's
the
difference
between
chore
and
editorial.
A
C
D
B
Let
me
capture
some
of
these
notes,
so
we
are
suggesting
changing
breaking
change
to
just
change,
we're
suggesting
adding
adding
a
new
question
about
whether
this
would
have
substantial
breaking
changes
to
it
and
to
explain
them.
B
B
B
Yeah,
yeah
and
and
noting
that
some
of
the
subsequent
questions
may
not
apply
to
all
types.
E
A
I
don't
think
that
they
need
to
be
available
before
opening.
I
think
that
we
need
general
consensus
on
changes
they
seem
like.
I
would
assume
that
this
is
like
for
anything,
that's
like
chore
or
editorial.
This
is
irrelevant
for
changes
yeah.
We
want
to
know
that
implementations
will
follow
and
definitely
for
breaking
changes
which
carry
larger
risk,
but
that
is
like
typically
something
that's
already
covered
in
the
you
know.
Consensus
model
of
the
group.
E
A
pr
just
for
discussion
sake,
and
so
I
think
it
should
be
fine
to
leave
those
blank
if
they're
not
yet
available,
just
if
they
happen
to
be
available.
To
put
it.
I
just
want
to
make
it.
C
C
Well,
it's
not
that
it's,
but
the
town
is
fine.
It's
just
yeah
like
like
michael
said
right.
If
I'm
someone
new
here
and
I
see
the
template,
I
think
I
have
to
fill
all
the
fields.
D
B
B
B
B
Okay,
thank
you
so
we'll.
B
B
Next
topic
I
was
going
to
so
this
is
about
the
app
history,
api
proposal
and
we're.
We
have
discussed
a
little
bit
about
how
this,
how
our
own
performance
timeline
works
with
different
types
of
navigations
and
app.
History
is
going
to
be
introducing
some
new
types
of
navigations.
If
you
were
single
page
app
style
navigations,
you
know,
I
know
that
you
had
talked
back
and
forth
with
dominic
a
little
bit
on
this
issue.
Do
you
want
to
go
over
a
little
bit
and
I'll
scribe
sure.
A
A
Essentially
so
dominic
outlined
a
way
in
which
he
feels
we
should
expose
soft
navigation
so
so,
first
of
all
like
maybe
there
is
some
like
background
missing
on
the
app
history.
Api,
dominic
de
nicola
and
others
are
working
on
a
new
new
and
improved
history,
api
that
will
enable
better
control
over
better
and
tighter
control
over
what
a
navigation
like
a
soft
navigation
is
and
will
enable.
A
The
browser
to
you
know
know
when
an
intent
for
soft
navigation
is
happening
rather
than
today,
where
essentially
developers
intercept
a
random
click
event
and
then
push
state
a
url
change
and
anything
in
between
can
like.
There
is
no
clear
way
to
say
when
the
navigation
started
or
ended.
The
app
history
api
gives
us
a
clear
point
in
time
in
which
a
navigation
started.
A
It
gives
us
indication
on
whether
it
is
user
initiated
or
not,
and
also
includes,
like
a
promise
based
api
that
essentially
enables
developers
to
resolve
the
navigation
whenever
they
feel
that
the
navigation
is
completed,
which
gives
us
a
duration
dominic's
plan
like,
and
maybe
I
can
best
just
present,
that.
A
I'll
present
a
dominic's
plan
where
he
suggested,
I
think,
a
new,
a
new
performance
entry.
A
Yeah
so
basically
same
document,
navigation,
performance,
entry,
that
looks.
B
B
A
A
Yeah
same
document
navigation
entry
and
which
essentially
has
a
boolean
indicating
whether
it
was
successful
or
not.
I
think
it
also.
The
duration
is
a
result
like
a
time
diff
between
the
time
in
which
the
navigation
was
like
the
start
time
and
the
time
in
which
the
promise
was
resolved,
and
this
is
like
it's
interesting
for
like
from
an
api
surface
perspective,
because
it
doesn't
expose
all
the
zero
entries
that,
like
essentially
for
the
regular
performance
navigation
entry.
A
A
Essentially,
a
single
buffer
for
all
navigation
entries
which
this
because
this
is
like
observing
a
completely
separate
navigation
type,
we'll
need
a
separate
observer
or
an
observer
that
observes
multiple
defend
tags,
which
is
something
we
are
trying
to
discourage.
A
So
essentially,
I
think
that
it
would
be
like
good
to
get
the
group's
opinion
on
what
the
right
api
shape
for
that
would
be.
Do
we
want
separate
observers
for
separate
navigation
types,
or
do
we
want
all
of
them
to
be
piled
up
in
the
same
array
as
they
are
now?
A
One
option
that
dominic
mentioned
like
that
could
be
interesting,
is
to
have
a
single
keyword
for
observing
all
those
different
navigation
entry
types,
but
still
have
different
entry
types
that
are
being
accumulated.
So
we
have
performance,
navigation,
entry
and
then
same
document,
navigation,
entry
and
bf
cache
navigation
entry,
and
they
won't
have
zero
size
at
like
zero,
valued
attributes
that
are
not
meaningful.
A
A
Yes,
that's
the
yeah
or
yeah,
that's
so
that
is
different
from
what
dominic
was
suggesting.
But
maybe
this
is
a
better
and
more
backward
compatible
way
of
tackling
this.
So
we
like
you,
can
observe
navigation,
which
just
gives
you
the
traditional
one.
Maybe
you
can
observe
multiple
like
if
you
just
interested
in
bf,
cache,
navigation
or
just
in
same
document
navigation,
you
can
observe
them
and
then
we
will
have
a
keyword
of
all
navigations.
A
That
will
give
you
all
those
types,
maybe
that's
the
just
to
ensure
that
from
a
backward
compatibility
perspective,
I
know
that
we've
looked
into
extending
the
like
we've
looked
into
extending
the
navigation
array
and
that
is
web
compatible.
A
But
it
is
possible
that
some
of
that
code
assumes
performance,
navigation
timing,
entry
and
looks
into
attributes
that
will
now
be
undefined.
If
we
will
all
the
sudden
switch
the
entry
from
underneath
existing
code.
A
Yeah
does
that
make
sense
to
folks
any
opinions
for
or
against
any
of
the
proposed,
like
api
shapes.
E
So
I
don't
know
that
I
fully
grok
all
of
the
new
ones
you
just
mentioned.
I
hope
to
take
a
closer
look.
I
just
wanted
to
say
that
if
the
goal
of
throwing
them
all
into
a
single
bucket
is
only
to
know,
when
is
a
good
time
to
slice
all
entries
and
to
say,
like
hey,
there
was
a
bit
of
a
reset
here
or
something
changed.
E
Then
that
makes
sense.
But
then
visibility
or
idleness
of
sessions
sometimes
gets
thrown
into
that
conversation,
and
so
would
we
want
to
expand
to
be
abstract
enough
to
handle
in
the
future
any
of
these
types
of
other
things
that
could
slice
and,
if
not,
if
it's
very
specifically
narrowly
focused
on
navigations,
because
we
want
to
know
thing,
the
difference
between
bf
cache
and
the
app
history
is
the
url
it
changes,
and
so
the
place
where
you
would
want
to
record
these
things.
E
There
is
a
there
is
a
distinct
property
of
one
of
them
such
that
I
would
want
to
handle
it
custom
anyway,
or
maybe
we
want
to
like
expose
that
for
all
navigation
types
or
whatever
it
is
so
anyway.
Those
are
just
two
things
that
add
extra
nuance.
There
I
would
say
like
it
makes
sense
to
me
that
I
might
want
to
listen
for,
like
any
reason
to
reset
or
stop
recording
or
whatever.
E
A
Think
that
slicing
is
not
the
reason
here,
because
we
talked
about
navigation,
ids
and
essentially
having
some
counter
that,
for
each
future,
entry
tells
you
which
navigation
id
it
correlates
with,
and
I
would
expect
those
like
each
new
navigation
entry
will
have
a
new
navigation
id
that
will
enable
you
to
do
the
slicing.
Based
on
that.
A
Maybe
it
makes
sense,
but
I
think
it's
like
it
doesn't
necessarily
impact
the
api.
E
Shape,
okay,
is
it
currently
possible
to
get
the
url
in
the
case
of
an
app
history,
navigation
where
you
might
register
a
listener
after
the
fact
such
that
you
have
old,
buffered
values
only
like
I
know
that
if
you're
currently
listening,
you
can
just
read
the
url,
but
is
that
something
that
we
want
to
add
to
the
entry?
I
didn't
see
it
in
the
proposal.
I.
A
Think
we
do
and
that's
a
good
point
I
also
really
like.
While
you
were
talking
about
urls,
I
realized
that
I
haven't
seen
urls
as
part
of
the
entry
so
yeah.
I
think
it
makes
sense
for
yeah
for
the
entry
to
say
like
provide
that
attribution,
because
it's
meaningful
for
developers
that
are
collecting
it.
B
For
you
know
for
me
like
getting
notifications
from
a
single
observer,
or
you
know,
multiple
different
observers
that
I
have
to
merge,
but
but
they
have
to
all
be
handled
slightly
different
anyway,
like
it
seems
it
seems
reasonable
to
do
it
either
way.
Honestly,
okay,.
A
Okay,
that's
fair,
okay,
so
maybe
an
action
item
folks
is
to
like
hop
over
to
the
pr
and
see
if
this
is
something
that
you
know.
If
you
have
strong
opinions,
please
voice
them
on
that
pr.
I
think
it
points.
C
One
question
so
is
the
is
the
idea
to
also
surface
this
new
entry
type
for
back
forward?
Navigations.
Sorry,
if
you
said
that
already,
but.
A
So
I
think
back
forward.
Navigations
are
definitely
different
than
same
document
right,
so
the
the
entry
name
would
be
very.
A
The
the
idea
is
not
necessarily
to
use
the
same
entry
types
for
bf
cache
navigations.
I
originally
thought
for
bf
cache
to
reuse,
performance,
navigation,
timing,
entries
and
then
just
add
a
new
navigation
type
there.
A
C
Yeah,
because
I'm
just
thinking
this
nbf
cache
navigation
seems
a
little
similar
to
this
one,
in
that
the
information
we
would
provide
is
perhaps
quite
similar,
whereas
navigation
timing.
So
most
of
the
attributes
are
about
the
network
right.
A
Yeah
the
so
the
information
this
provides
is
a
success
boolean,
I
think
it
like
michael
said.
It
should
also
provide
the
url
that
bf
cache
doesn't
necessarily
have
to
provide
it,
and
the
duration
is
defined
based
on
the
promise
where
for
bf
cash,
I'm
to
be
honest,
not
100,
sure
what
we
should
define
there,
because
unload
doesn't
refire,
and
I
don't
know
like
what
that
would.
C
Translate
that
I
guess
it's
probably,
it
would
be
different
semantics
in
here
yeah,
so
I
I
guess
we
need
to
answer
that
question
though
right
like
do.
We
want
the
same
type
of
entry
for
this
app
history
versus
bf,
cache
and
there's
other
things
that
are.
We
haven't
even
talked
about
like
portal
activation,
and
things
like
that
I
like
do.
We
want
to
have
like
10
different
types
of
navigation
entry
types
like
that
doesn't
seem
great
yeah,
so.
E
Question
so
beyond
the
the
potential
downside
of
registering
multiple
observers,
I
think
it
really
also
comes
down
to.
Are
we
actually
going
to
expose
a
navigation
id
on
all
other
entries?
Because
if
you
do
then
you're
going
to
be
incorrect
by
default,
unless
you
actually
register
for
all
of
them
like
you'll,
have
to
you
might
not
be
able
to
match
up
to
the
right
one
and
so
having
them
all
share.
A
Yeah,
but
it
was
pointed
out
in
a
past
call
that
times
can
overlap
in
in
weird
ways
that,
like
we
want
a
more
deterministic
id,
which
will
also
be
more
ergonomic.
That's
right.
E
Is
at
all
possible
if,
if
it
is,
if
it
is
implementable
without
implications,
I
think
it
would
be
interesting
if
the
navigation
id
was
the
index
into
the
into
the
set,
as
opposed
to
having
to
go
to
a
bunch
of
different
observers
and
a
bunch
of
lists
and
find
the
one
that
has
to
match
up.
That
would
be
one
advantage
like
it
would
be
more
correct
by
default.
A
B
I,
what
you
said
resonated
with
me,
michael
about
making
sure
to
future
proof
this.
If
you
wanted
to
be
a
good
web
developer,
you
would
have
to
you
could
not
just
start
listening
for
the
ones
that
you
cared
about,
because
if
we
ever
added
another
type
of
navigation
in
the
future,
you
would
be
missing
that
id
unless
you
updated
your
app
to
also
capture
or
to
also
listen
for
the
other
new
feature
type.
B
A
Yeah
anyway,
it
seems
worthwhile
to
continue
to
think
about
that
and
see
how
we
can.
A
Yeah,
basically,
there's
a
trade-off
here
between
visibility
and
then
trying
to
fit
all
the
navigations
into
like
a
single
entry
type
or
expose
multiple
entry
types
and
then
have
developers
switch
on
them
versus
having
completely
separate
observers.
That
will
require
you
to
yeah
to
know
of
all
the
things.
A
And
yeah,
I
so
I'd
appreciate
all
your
thoughts
on
the
like
on
the
pr,
and
we
can
then
discuss
it
further
there
and
I
think
we
need
like
eventually
we'll
need
to
align
what
we're
doing
with
what
the
app
history
folks
are
doing.
B
Sounds
great,
thank
you,
yo
for
leading
us
in
that
I
do
have
another
one.
That
is
something
that
you
are
proposing
of.
This
is
resource
timing,
we're
gonna
switch
to
resource
timing,
resource
timing,
number
273,
oh
yeah
early,
exposing
early,
hints
yeah.
A
Yeah,
so
this
turned
out
less
complex
than
I
initially
thought
it
would
be.
Let
me
there,
though,
essentially
the
current
proposal
is
to
just
use
the
initiator
type
and
do
something
useful
with
it
for
a
change
and
just
have
the
value
of
initiator
type,
the
early
hand.
A
So
I
think
it's
a
very
neat
proposal
compared
to
where
I
started
here,
and
it
also
has
a
side
effect
of
essentially
being
transparent
from
the
resource
timing.
Spec
perspective.
A
It
just
needs
that,
like
from
a
spec
perspective
after
the
fetch
integration,
the
color
to
the
color
to
fetch
needs
to
pass
along
early
hint
as
the
initiator
type,
and
that
will
just
be
recorded.
So
I
think
it's
a
pretty
neat
solution
to
that
particular
problem.
A
The
background
here
is
that
the
chrome
loading
team
is
starting
to
play
around
with
an
early
hints
origin
trial,
and
one
of
the
partners
wanted,
like
one
of
the
requirements,
is
to
yeah
be
able
to
measure
whether
or
not
early
hints
were
actually
triggered
so
having
that
value
in
resource
timing
is
essential
for
the
origin
trial.
That
seems
like.
A
Essentially,
it's
like,
like
I
said
it,
doesn't
involve
a
spec
change
here.
It's
just
a
spec
change
on
the
early
hints
part,
so
I
think
that
if
the
origin
trial
is
successful-
and
you
know,
chrome
decides
to
implement
and
ship
early
hands.
I
think
that
this
is
like
the
right
way
to
do
that
in
terms
of
reporting.
A
A
So
initiator
type
at
the
moment
is
not
super
useful,
at
least
in
my
opinion,
for
preloads
the
initiator
type
is
link
for
all
of
them,
regardless
of
what
is
that
preload
and
what's
the
like?
What
is
its
destination,
so
I
think
losing
like
and
I
to
be
honest,
I'm
not
sure
what
is
currently
being
recorded
for,
like
header
based
preloads.
A
A
D
D
Hey
yo,
so
I
think
when
I
was
looking
at
this,
the
concern
I
had
was
like
early
since
it's
going
like
it's,
a
chrome,
only
feature
right
and
then
they're
exposing
like
something
only
works
like
only
going
to
be
existing
chrome,
sound.
Now
the
rest
solution
to
me,
or
am
I
missing
something.
A
So
early
hints
right
now
is
a
no
browser
feature.
It
is
so
there's
an
itf
standard.
There
is
no
web
spec
for
that
at
the
moment,
but
I
know
that
the
loading,
the
chrome
loading
team
is
planning
to
work
on
one.
Basically,
it
needs
some
fetch
integration
to
understand
what
like
how
it
interacts
with
csp
and
other
things.
A
Right
now,
it's
like
in
an
origin
trial.
I
think
the
origin
trail
is
out,
so
this
is
being
experimented.
It's
not
yet
web
exposed
when
it
will
be
exposed.
I
think
that
the
current
piping
of
resource
timing
aligns
well
with
the.
A
You
know
the
fact
that
the
color
tells
like
the
caller
passes
along
to
the
algorithm.
What
the
initiative
type
is
so
yeah.
Essentially,
this
doesn't
require
any
real
changes
on
the
resource
timing
front.
It's
just
changes
on
the
color
to
the
color
to
the
fat
stack
that
will
initiate
the
early.
D
Yeah,
I
think,
as
long
as
it's
now
like
really
changing
the
rules.
Timing,
I'd
be
fine,
although
I
don't
have
a
clear
picture
of
how,
like
the
color
hints
the
early
thing,
but
I
guess
I
can
look
to
that
after.
A
Cool
I
can
yeah.
Let
me.
A
A
Yeah
suggested
as
a
replacement
for
yeah
for
a
replacement
or
a
supplemental
feature
for
like
h2
push.
It
covers
some
of
the
same
use
cases.
It
was
actually
driven
by
a
colleague
of
patrick
hammond
here
from
fastly
and.
A
Basically,
the
the
chrome
loading
team
is
playing
around
with
that
to
see
what
it
gives,
and
the
hope
is
that
you
know
the
experiment
and
the
this
reporting
of
when
early
hints
were
triggered
or
not,
would
enable
various
partners
to
report
back
when
you
know
benefits
in
terms
of
performance
and
otherwise.
B
Sounds
good
so
the
call
to
action
there
is
to
provide
feedback
into
that
particular
app
history.
Well,
I
guess
so
that
pull
request
is
merged,
which
one
the
app
history
pull
125.
B
A
Yeah,
so
I
think
the
action
item
here
is
that
I
can
close
this
issue
because
it
will
just
fall
out
of
the
yeah.
B
Sorry,
I
said
just
bring
it
back
to
the
last
discussion
around
history.
We
were
going
to
provide
feedback
about
the
api,
shape
and
stuff,
but
looking
at
it
that
merge
request
is
merged.
Do
we
have
another
forum
where
we
want
to
just
like?
Should
we
open
a
new
issue
in
our
repose
or
in
the
app
history,
repo.
A
It
may
make
sense
to
open
a
new
issue
on
navigation
timing,
maybe
or
on
performance
timeline,
to
see
we
can
coalesce
all
those
different
navigation
types
and
have
the
discussion
there.
It
may
be
the
best
yeah,
the
best.
B
B
A
Step
yeah.
B
B
Okay,
so
in
in
our
spec
we
have
the
next
top
protocol.
Getter
steps
are
to
isomorphic
decode
this
timing,
info's
final
connection,
timing
intervals,
and
my
I
guess
my
guess
is
that
changing
the
ideal
to
a
byte
string
just
avoids
that
word
are
those
few
words
in
the
spec.
A
Yeah,
so
this
is
essentially
like
a
spec
cleanup.
B
B
Issue
275
for
resource
timing
is
there's
no
mention
here.
I
can
just
share
my
screen
too,
because
why
not
no
mention
to
the
to
web
idl
in
conformance
section
something
I
guess
we
had
made
a
change
a
long
time
ago
pulled
out
the
web
idl
for
idl
fragments
a
little
lost
on
this
whole
issue.
To
be
honest,.
A
Marcos
seems
to
have
strong
opinions
on
why
we
shouldn't
have
yeah
like
why
we
should
mention
web
ideal
for
idl
fragments.
I
can
talk
to
marcus
and
see
what
yeah
again
like
I
can
take
an
ai
to
marcus
and
c.
E
B
Let's
see
okay,
so
the
next
one
is
in
the
fetch
spec.
We
have
tio
check
and
child
frame
navigations
opened
by
zeta
function
on
april
23rd.
I
don't
believe
we've
talked
about
this
yet
in
these
meetings,
although
it
also,
I
don't
think
we
have
those
on
the
call
have
commented
there.
So
I'm
not
sure
if
nicolas
ryov
want
to
give
a
brief
update
on
it.
B
Oh
sorry,
issue
fetch
one
two,
two
one
post
it
in
comments.
A
C
Yeah,
I
think
this
is
about
tau
being
improperly
specified
for
navigation
timing
and
for
iframe
resources,
because
they
go
through
a
different
navigation
path
in
the
fetch
spec
than
the
other
resources,
because
they
started
as
a
navigation
rate.
C
C
Yeah,
I
think
we
agree
what
the
thing
needs
to
do.
We
just
need
to
specify
it
like.
We
need
to
figure
out
how
to
specify
it
right,
like
it
shouldn't
have
a
different
behavior
than
if
it
was
say
an
image.
A
A
C
D
C
A
No,
it's
like
it's
a
change,
but
it's
not
a
breaking
change
yeah,
but
I
I
agree
that
if
we
are
all
aligned
that
would
significantly
reduce
the
urgency
yeah,
I
don't
know
where
the
like.
I
think
that
the
tao
has
are
not
using
iframes.
A
Yeah
as
part
of
the
like,
there's
an
ongoing
effort
to
improve
the
tests.
I
think
that,
as
a
part
of
it,
we
wanted
to
also
expand
the
test
surface,
to
also
cover
different
types
of
resources,
because
yeah
images
like
at
least
in
chromium
images
and
xhr,
are
different
types
of
loaders
and
iframes
are
definitely
a
very
different
beast,
so
yeah,
I
think
it.
A
The
first
step
is
probably
to
extend
the
tests
to
also
cover
iframes,
and
then
we
can
see
how
how
big
and
how
bad
of
a
problem
this
currently.
A
C
A
It
would
be
easy
for
someone
to
so
there's
like
the
new
test
frameworks
for
like,
essentially,
all
the
old
tau
tests
are
now
this
list
of
tests
and
they're
using
sync
x
hr
to
check
all
those
invariants.
A
I
think
that
testing
the
iframe
case
would
just
mean
adding
an
array
here
of
different
loading
functions
and
then
iterating
over
this,
like
that
array,
with
those
test
cases
and
as
far
as
I
like,
the
the
results
should
be
the
same,
so
it
like
yeah
so.
B
A
It
so
they
are
working
on
refactoring
I
like
yeah.
We
can
definitely
ask
and
see
if
they're
interested
in
also
expanding
test
coverage
on
this
particular
front,
let's
see
yeah.
Why.
B
A
Yeah
sure,
okay
yeah,
I'm
gonna,
send
it
to
me
too.
B
Okay,
it
is
201.
Thank
you,
everybody
for
whatever
time
it
is
your
time
zone
01
after
the
hour.
Thank
you
everybody
for
joining
today.