►
From YouTube: WebPerfWG triage call - October 17th 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
Regarding
moving
the
calls
an
hour
earlier,
I'm
getting
like
there's
some
survivorship
bias,
asking
the
group
this
cuz
you're
all
here,
but
I
didn't
hear
any
objections,
so,
like
I
think
we
will
be
moving
the
calls
to
be
at
this
time,
rather
than
so
10
a.m.
Pacific,
rather
than
11,
going
forward
to
accommodate
rios
k
if
yeah
unless
like
and
if
there
are
problems
with
that
in
the
future,
we
can
try
to
figure
out
a
different
time
that
works
well,
for
everyone
are
most
people.
A
A
A
Okay,
so
I
can
talk
about
that.
We've
talked
about
the
back
forward
navigation
type
and
what
it
should
do
a
bit
at
TPAC
and
then
had
a
bunch
of
feedback
from
Boris
regarding
the
current
definition
and
how
we
should
improve
it.
But
I
think
we
had
an
underlying
question
at
the
fact
that
we
didn't
really
know
the
answer,
which
is
what
do
we
want
back
forward,
navigations
to
look
like,
and
then
history
navigations
to
look
like
and.
C
A
C
A
Different
so
of
course,
so,
first
of
all,
I
I
wasn't
around
when
this
was
defined.
So
I'm
not
sure
my
understanding
is
that
it's
intended
for
history
related
pages
and
getting
the
sense
of
their
loading
times,
but
also
for
because
the
navigation
type
is
back
forward
and
history
doesn't
have
to
be
so
yeah
back
forward,
but
not
necessarily
BF
cash
related.
So
it's
related
navigation.
So
it's
reasonable
to
expect
it
to
have
different
characteristics
from
you
know,
navigate
operation
or
reload
operation.
D
Can
add
another
additional
bit
of
context,
so
there
some
people
like
internally
here
at
Google,
are
requesting
information
about
wanting
to
measure
now
that
chromosome
plenty
blackboard
cache
wanting
to
measure
how
long
it
takes
from
when
the
user
clicks
back.
Does
the
take
for
the
page
to
show
currently
that
information
is
not
exposed
anywhere
with
the
exception
of
in
Safari,
where
Safari
will
update
the
performance,
timing,
navigation,
timing,
l1
data,
and
that
was
useful
for
them
to
get
that
information
and
no
other
browser
has
an
information,
and
so
one
question
that
they
had
was.
D
Could
we
expect
something
that
allows
us
to
know
like
how
long
it
takes
to
come
out
of
the
VF
cache
and
and
then
we
could
compare
the
difference
between
that
and
how
long
it
a
regular
back
forward
history,
navigation
takes
so
there's
an
additional
use
case.
That's
not
currently
being
met
by
the
API
and
so
I.
Think
there's
a
question
of
like
is
the
current.
It's
what's
currently
happening
expect
what
we
want
and
then
also
can
we
either
update
that
or
add
a
new
entry
type
to
get
this
new
information
that.
E
F
D
A
Current
currently
exposed
the
attributes
of
that
entry.
That
won't
necessarily
make
sense,
so
we
need
to
think
through
what
each
one
of
them
will.
You
know
would
mean
in
the
bf
cache
case
and
then
there's
the
slightly
tangent
issue
of
the
fact
that
there
are
currently
compatibility
like
currently
it's
under
defined.
What
browsers
should
do
so?
Safari
is
doing
one
thing,
Firefox
is
doing
another
and
it
would
probably
like
for
l1.
It
would
make
sense
to
decide
on
a
single
behavior
and
stick
like
you
know,
a
line
and
everyone
to
that.
A
D
D
A
A
A
That
we
will
need
to
agree
on
for
l2,
for
that
case
would
be
whether
or
not
we
want
to
change
the
you
know,
change
the
l1
like
change.
The
already
dispatched
entries
and
I
tend
to
agree
with
Phillip
that
the
answer
to
that
is
no,
but
I,
don't
know
really
do
you
have
any
opinions
on
that
in
terms
of?
G
I
wouldn't
know
if
that's
actually,
in
addition,
I
was
just
simply
a
bug,
so
it
off
top
of
my
head
yeah
I'm.
Anything
like
useful
to
say
here:
okay,.
G
D
On
so
performance
timing,
dot,
you
know,
navigation,
start
and
I
think
some
other
some
other
properties
of
the
performance
timing
object
from
the
l1
specification,
not
from
the
like,
not
another
performance
entry.
Those
values
get
updated
when
the
page
comes
out
of
bf
cache
and
the
values
that
don't
apply
like
I,
don't
know
redirect
or
workers
start
up,
I
think
just
get
set
to
zero.
D
I
also
was
testing
this
and,
in
the
page
show
event
the
event
timestamp
property
is
set
to
something,
but
it's
not
set
to
the
same
thing
as
navigation
start
and
I.
Think
that
would
be
another
interesting
thing
to
find
out
what
browsers,
how
browsers
would
set
that
value
when
the
pages
come
out
of
the
bf
cache?
But
that's
not
super
relevant
to
this
particular
thing.
You
were
asking.
The
main
thing
you
look
at
is
that
performance
that
timing
navigation
start
is
updated
when
the
page
comes
out
of
bf
cash.
G
A
C
A
A
G
A
G
A
Bf
cash
chromium
doesn't
have
a
BF
cash
or
like
there's
work
in
progress
now
to
ship
one,
but
there
is
no
shipped
BF
cash
I.
G
A
A
A
A
C
C
C
In
the
example
there
we
load
a
website,
then
clicking
the
URL
address
bar
and
then
press
Enter,
it's
over
for
Chrome
browser.
It
is
treated
as
a
reload,
and
so
the
navigation
type
is
set
to
reload.
But
some
people
found
a
bug
saying
that
this
should
not
be
treated
as
a
reload
because
it
was
not
triggered
by
a
reload
operation
because
it
was
triggered
by
getting
the
entering
the
URL
bar.
So
I
I
want
clarification
about
what
is
the
actual,
correct
behavior
here.
A
A
A
A
A
E
E
A
A
C
F
A
A
I
think
that
this
is
what
Chrome
currently
is
doing
and
I
don't
know
if
that,
like
it
sounds
like
a
UI
decision
that
shouldn't
necessarily
make
its
way
through,
like
it
shouldn't
be
in
the
spec,
so
the
spec
should
probably,
instead
of
not
linking
to
anything
when
it
comes
to
reload
operation.
We
should
you
know,
link
to
the
concept
of
a
reload,
triggered
navigation,
somehow
and
define
it
defined
reload
through
that,
but
that
won't
solve
your
issue.
A
A
E
A
E
A
B
B
Yeah
I
mean
I
think
there
are
implications
of
this
that
are
broader,
and
some
of
them
are
super.
Weird
in
terms
of
things
like
hitting
enter
in
the
address
bar
does
something
different
than
hitting
reload.
If
the
you
got
to
the
page
via
post
and
hitting
enter
in
the
address
bar
versus
hitting
refresh,
does
something
different
for
same
side
cookies
like
in
terms
of
whether
or
not
the
the
same
side
cookies
get
sent,
and
so
I
think
this
is
a
broader
issue
in
the
web
platform
than
just
than
just
the
implications
on
navigation
topics.
B
B
A
G
B
The
idea
that
there
are
interface-
you
you
there
are
multiple
mechanisms
in
chrome
that
trigger
something
like
a
reload,
and
it
sounds
like
this.
Conversation
originated
out
of
the
fact
that
hitting
enter
in
the
address
bar
for
navigation
entries
is
the
same
as
hitting
the
refresh
button,
and
my
point
was
merely
that
that
may
be
true
for
navigation
entries,
but
it
doesn't
appear
to
be
true
for
at
least
two
other
behaviors
of
chrome,
yeah,.
A
G
G
A
C
A
Now
that
it
is,
do
you
know
which
spec
would
make
sense
to
file
that
broader
issue
or
not?
It
sounds
like
HTML,
because
it
currently
has
the
real
trigger
a
navigation
things.
So
maybe
there
need
to
be
multiple
types
of
that,
but
yeah,
and
it
does
different
things
based
on
that,
like
it's,
basically
a
flag
that
yeah,
it
sets
a
reload
navigation
flag.
That
does
various
thing
as
far
as
fetch
is
concerned,
and
maybe
there
need
to
be
multiple
flags
that
do
you
know
that
do
this
post
to
get
conversion
or
the
same
site.
C
A
So
but
but
basically
what
I'm
saying
is
this
seems
like
a
broader
issue
that
we
don't
like
it
doesn't
necessarily
a
navigation
timing
issue.
Maybe
it's
an
HTML
issue
and
we
need
to
see
if
what
chrome
is
doing
has
a
matching
spec
concept
and
if
other
browsers
are
doing
something
similar
in
response
to
different
UI
elements
and
whether
you
know,
what's
the
rationale
behind
it
and
this.
These
are
all
questions
that
I
don't
currently
have
answers
to.
A
A
If
I
read
the
current
definition
correctly,
then
we
can
like
we
can
verify
whether
chrome
and
other
browsers,
consider
this
reload
navigation
or
not,
and
make
sure
that
this
Maps
correctly
to
the
you
know
to
the
HTML
spec
concept
like
the
is
reload
navigation
concept.
But
it's
it
like
reload
trigger
navigation
concept,
but.
A
A
Yeah
it's
worthwhile
to
test.
Let's
see,
you
know
what
the
rationale
behind
like
so
test
as
well
as
just
you
know,
ask
folks
what
is
the
rationale
behind?
It
was
different
behave
for
different
UI
elements
and
whether
this
is
something
that
should
be.
You
know,
aspect
concept
or
not
sure.
So
what
are
the
action
items
so
I
think
the
action
items
are
one
to
map
the
current
reload
flag,
as
well
as
the
the
navigate
like
the
reload
type
and
the
navigate
type.
A
We
need
to
map
them
to
the
navigation,
like
reload,
trigger
navigation
concept
and
then
make
sure
that
navigate
is
none
of
the
above
kind
of
concept
in
element
and
we
don't
like
it
doesn't
strictly
define
UI
elements
and
it
doesn't
yeah.
It
doesn't
necessarily
answer
your
question
and
right
and
then
your
question
is
I.
Think.
A
A
So
if,
as
far
as
chrome
is
concerned,
it
is
a
reload
and
it
does
trigger
those
different
loading
characteristics.
Then
we
probably
want
to
report
that
as
a
reload,
regardless
of
the
UI
element
that
through
which
this
reload
was
triggered,
and
then
there's
the
higher-level
issue
of
different
UI
elements.
Do
different
reload,
like
things
and
maybe
we
wanted
to
find
that.
But
that
will
require
some
research
and
it's
also
seems
like
a
you
know,
about
DML
and
not
like
out
of
scope
for
navigation
timing
by.
A
Yeah,
okay,
so
does
that
make
sense
for
everyone?
Can
we
move
to
you
move
to
the
next
one
yep
and
the
next
one
for
a
navigation
timing
is
of
117?
Basically,
we
modified
the
previous
timing,
allowed
checks
that
didn't
really
make
sense.
We
changed
them
to
the
same
origin
checks.
So
there
are
various.
A
A
Timing,
allow
origin
doesn't
make
so.
First
of
all,
it's
not
clear
how
like
from
a
spec
perspective.
Currently
the
origin
of
the
previous
page
is
not
something
that's
piped
to
the
next
page,
and
it's
not
clear.
Basically,
the
way
that
it
was
defined
was
that
the
page
that
is
linking
to
the
current
navigation
has
control
over
various.
C
A
A
A
A
C
I
think
what
we
need
to
do
is
the
attribute
debtors
should
be
trivial
and
then
in
resource
timing.
We
need
to
move
the
algorithmic
parts
outside
of
the
attribute
Gators
and
move
them
somewhere
when
they
are
set,
so
that
that
part
of
the
code
only
runs
for
the
resource
timing
processing
model,
but
not
the
navigation
timing,
yeah.
G
A
A
F
C
A
Okay,
so
yeah
that
yeah,
that
makes
sense
yeah
cuz,
because
we
try
to
consult
like
they
had
very
different
definitions,
and
then
we
try
to
consolidate
that.
But
yeah
looks
like
it's
all
dated
too
much
so
yeah,
okay,
but
that
makes
sense,
and
otherwise,
in
the
minutes
that
we
have
left,
there
are
a
couple
of
requests
idle
callback
issued
rios
k.
I'm
yeah!
I
just
wanted
to
say
that
I'm
super
excited
to
see
you
making
progress
on
those
anything
in
particular
that
we
should
discuss
there
or
I.
Think
one
of
the
nine
I.