►
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
Time
to
discuss
everything
this
time,
so,
let's
see
the
performance
timeline.
Api
is
a
thing
and
it's
generally
great,
but
it's
got
one
big
glaring
problem
and
we've
talked
to
a
number
of
analytics
providers
to
find
out
that.
Yes,
this
is
a
real
problem.
People
are
facing
and
that's
the
fact
that
they're
web
pages
are
made
of
frames
and
we
don't
allow
basically
anything
to
cross
that
frame
boundary
to
go
across
origins,
and
this
is
obviously
a
good
thing
right.
A
The
web
privacy
and
security
model
depends
on
this,
but
it
still
means
that
it's
a
huge
blind
spot
for
this
api.
A
You
can't
know
if
you
know,
as
an
analog
pro
you
can't
know
if
some
cross-origin
frame
is
actually
stalling,
if
it's
failing
to
load,
if
it's
causing
a
bad
user
experience
right,
there's
literally
no
way
to
tell
this
from
the
perspective
of
the
top
level
page,
you
can
get
around
some
of
it
with
custom
script,
but
the
problem
is
that
you
need
to
have
that
script.
A
You
need
to
control
the
script
on
all
of
the
frames
in
order
to
be
able
to
do
this,
and
it
would
be
nice
if
you
didn't
have
to
do
that,
because
there's
a
lot
of
embedded
third-party
frames
that
are
embedded
by
a
lot
of
different
embedders
and
having
them
run
everybody's
script.
All
the
time
is
likely
impossible.
A
A
And
we
do
this
in
a
standard
way
that
doesn't
require
custom
script
on
the
child
frame.
So,
let's
see
there
is,
can
I
switch
to
this
dock
here?
Let
me
see
so.
I've
got
a
dock
that
I
shared
all
right
that
should
have
been
attached
to
the
agenda
for
this
meeting
here,
which
is
just
called
a
cross
cross
frame
performance
timeline.
A
A
A
The
embedding
site
gets
has
to
explicitly
request
that
it
gets
performance
timeline
entries
from
the
child
frames
so
that
we
don't
break
any
existing
any
existing
deployments
just
by
having
a
child
frame.
Opt-In
and
also
you
can
distinguish
those
timeline.
Events
from
subframes
from
the
ones
coming
from
your
main
page.
A
We
don't
want
to
just
extend
that
to
frames,
because
it
has
a
significantly
different
semantics
here,
but
we
could
have
something
like
a
performance
allow
origin
header
which
would
allow
you
to
say,
okay.
Well,
what
origins
are
allowed
to
request
my
timeline
events,
I'd
like
to
avoid
minting
a
new
header
and
actually
just
make
this
a
document
policy
configuration
point.
A
So
we've
already
shipped
document
policy
for
a
couple
of
things.
This
would
basically
add
a
new
token
to
it.
In
this
case,
I
just
called
it
share
performance
timeline
with
and
it
would
take
a
list
of
origin,
so
you
could
say
either
you
know,
share
my
timeline
with
anybody
or
just
share
it
with
these
particular
origins,
who
I
know
and
expect
to
be.
Embedding
me.
A
And
basically,
once
you
do
that
that
should
be
enough.
Let's
get
past
the
things
that
we
thought
about
and
discarded,
but
anybody
can
go
and
take
a
look
at
these.
There
we
go.
So
what
we
want
to
do
is
extend
the
performance,
observer
methods
to
have
an
additional
boolean
to
say,
please
include
frames,
and
if
you
say
yes
to
this,
then
you
will
start
getting
performance
timeline.
Events
from
all
of
the
child
frames
that
have
opted
in
the
non-observer
methods
would
similarly
have
a
boolean
like
that
attached
to
them.
A
And
then
in
the
response,
when
you
actually
start
getting
these
events,
what
I
think
the
simplest
way
to
do
here-
and
this
is
certainly
up
for
discussion-
is
basically
just
include
in
the
javascript
object-
a
reference
to
the
window
object
of
the
frame
that
was
the
source
of
the
event.
A
There's
some
talk
here
as
well
that
you
could.
We
could
provide
like
index
down
the
frame
tree
level
so
that
you
could
navigate
to
it,
but
I
believe
that
the
two
are
basically
equivalent
and
having
a
window
means
that
you've
basically
got
something
that
you
could
post
message
to.
If
you
want
to
do
additional
things
to
it,
without
having
to
go
search
for
that
frame,.
A
Right
so
we
just
had
a
basically
a
source
object:
the
performance,
entry,
idl
and
then
the
document
ends
with
here's
an
example
of
how
you
would
actually
use
this
in
practice
right.
So
the
embedded
page
would
have
a
share
timeline
with
giving
the
top
level
document.
A
The
top
level
would
say
make
me
a
new
performance
observer
by
the
way
I
want
to
get
child
child
frame,
source
performance
entries
and
then
once
it
starts
getting
those
in
its
callback.
It
can
look
at
the
source
and
it
can
segment
those
it
can
identify
them.
It
can
pinpoint
where
problems
are
and
report
those.