►
From YouTube: WebPerfWG call - January 30th 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
Okay
and
we
can
get
started
yes
on
the
agenda
today,
we
have
you
can
like.
Basically,
we
will
continue
this
impending
discussion
from
last
week
and
then
talk
about
page
visibility
and
the
meaning
of
the
word
hidden
in
terms
of
just
before
we
get
started
the
administer
like
in
terms
of
administrative
stuff.
So,
first
of
all,
this
call
is
recorded
and
will
be
posted
online
and
for
the
next
call
we
are
currently
scheduled
to
have
it
two
weeks
from
now
on,
February
13th
same
time
as
now
does
that
work
for
everyone?
A
A
B
All
right,
okay,
cool
cool,
so
yeah.
This
is
a
follow
up
from
some
of
the
discussions
we
had
last
week.
Last
time
we
left
off
talking
about
the
issue
of
cross
urgent
iframes
moving
and
potentially
causing
the
frame
that
was
predicted
to
receive
input
via
isn't,
but
pending
differing
from
the
frame
that
actually
receives
an
event
dispatched
so
yeah
it
was
pretty
insightful.
It
was
really
nice
to
hear
from
other
implementers.
B
We
realized
that,
like,
even
though,
like
from
security
might've
signed
off
on
this,
it's
possibly
not
going
to
be
as
efficient
of
guarantee
for
all
user
agents
and
we're
going
to
reach
out
to
the
tag
and
Yoav
and
philip.
I
believe
you
made
a
suggestion.
Last
time
too,
reach
out
to
the
webapp
SEC
working
group
is
weller.
A
We
could
I
guess
for
me.
There
are
like
a
couple
of
questions
here
in
terms
of
mitigate,
like
basically
I'm
wondering
if
we
cannot
mandate
that
the
head
testing
will
be
done
either
done
once
or
if
it's
done
twice.
If
the
result
is
not
matching,
we
discard
the
result
because,
on
the
one
hand,
I
I
saw
the
assessment
of
Chrome
security
folks
and
they
don't.
A
B
The
locking
events
to
origin
concept
that
was
discussed
last
call
I
can't
help
but
think
that
it
might
leak
information
about
when
events
are
like
they
were
pending
to
one
frame
but
get
dispatched
to
another
frame.
The
scenario
is
that
why
the
slides
here
but
I
can
imagine
a
case
where,
if
you
like,
target
an
input
event
to
a
frame,
isn't
impending
returns,
true
for
that
frame,
and
then
it
doesn't
receive
the
appropriate
or
a
related
non-event.
You
could
sort
of
infer
that
the
event
was
dispatched
out
of
its
frame,
so.
A
Yeah,
but
that
is
the
leak
that
exists
in
the
current
implementation,
so
in
the
connotation
you
can
deduce
that
an
event
was
dispatched
to
another
frame.
The
single
hit
test
case:
either
you
like
you,
get
the
event,
even
though
you,
your
iframe,
moved
right
or
you
get
the
isn't
impending
and
don't
get
the
event
in
which
case
you
know
that
you
had
an
event
coming.
B
A
I
I
agree
that
this
should
have
here
is
pretty
vague,
but
but
if
you
mean
came
I
mean
if
you
maintain
a
single
hit
test
and
then
dispatch
it,
then
yeah
I,
don't
know
it's
worthwhile,
maybe
to
discuss
those
three
options
and
see
what
you
know.
What
folks
beyond
this
group
say
so
either
tag
review
or
maybe
web
sack.
You.
C
C
C
Why
you
know
it
because
from
what
the
contents
perspective
you
can
tell
when
like
testing
water
or
car
anyway,
right
so
mm-hmm
a
scrolling,
there's
the
this
asynchronous
condition
of
what,
when
a
user
clicks
versus
one
click
event
is
actually
differ
already,
of
course,
so
in
anything,
it
just
improves
to
like
the
synchronization
program
between
the
actual
user
clicking
versus
when
the
event
is
the
river.
Yes,
I
think
the
approach
is
slightly
pro-football.
Okay,
cool.
B
B
Okay,
so
one
of
the
big
pieces
of
feedback
we
got
a
TPAC
was
that
I'm
using
Dom
event,
types
for
the
input
type
filter
wasn't
quite
ideal.
So
for
a
bit
of
context
here,
the
way
the
current
origin,
trial
version
and
explainer
version
of
isn't
book
pending
works
is
it
takes
in
a
list
of
Dom
events
in
which
it
can
ask
the
you
a
hey.
Let
me
know
slash
return,
true.
B
If
you
think
that
any
of
these
Dom
events
would
be
dispatched
if
I
were
to
yield,
and
so
the
reason
behind
this
originally
was
that
we
wanted
to
provide
user
agents
with
a
way
to
avoid
yielding
too
much
for
continuous
events.
So,
for
example,
you
don't
want
to
be
interrupting
long-running
work
for
a
most
move.
If
all
your
site
has
is
like
a
bunch
of
click
event,
listeners
and
you
don't
really
want
to
you're
not
going
to
do
any
work
anyway.
B
So
we
had
an
idea
instead
of
providing
fine-grained
a
per
event
control.
We
try
to
solve
that
problem
that
we
had
initially
of
picking
the
right
set
of
events
in
a
more
generic
way
through
providing
a
simple
like
is
continuous
flag
into
the
API,
and
we
think
that
this
probably
addresses
the
most
use
cases.
People
had,
with
the
exception
of
situations
where
say
somebody
might
be
interested
in,
say
a
scroll
event
handler,
but
not
a
mousemove
event
handler
so
yeah
additional
thoughtfulness
for
the
most
part.
B
So
this
is
more
detail
in
the
next
slide
about
like
how
we
might
define
a
continuous
event
in
sort
of
like
a
implementation
and
event
agnostic
way.
Typically,
rapid
succession,
while
providing
like
in
the
initial
I,
expect,
for
instance,
some
examples
of
which
Dom
events
might
be
considered.
Continuous
events
such
as
like,
as
I
mentioned
before
most
move,
will
touch,
move,
etc,
and
yet
we
expect
the
most
users
of
this
API
will
not
be
interested
in
these.
How
for
the
rare
cases,
we
want
to
continue
exposing
this
information.
D
A
B
I
was
gonna,
mention
we've
been
working
with
Nicholas
and
we're
going
to
try
to
unify
that
definition
between
the
two
aspects.
So
have
the
idea
of
a
continuous
event
task,
which
is
what
is
input
pending,
looks
for
which
dispatches
a
continuous
event,
which
is
the
same
definition
shared
with
event.
Timing.
A
B
B
Obviously
we
want
to
avoid
the
hassle
that
is
setting,
like
particular
headers
or
anything
like
that
or
a
static
initialization.
So
we
think
that
this
may
be
like
pretty
straight
or
they
accomplished
just
by
using
an
construct
which
gives
us
the
additional
benefit
of
extensibility
later
down
the
line
and
allowing
the
UA
to
essentially
like
compile
it
so
to
speak
into
a
more
efficient
representation.
B
This
was
sort
of
inspired
by
the
fact
that,
with
the
original
implementation
of
is
impending,
it
turned
out
to
actually
be
fairly
costly
to
check,
to
do,
string
matching
and
cross
all
the
event
types
that
were
provided
into
the
API
for
the
origin
travel
and
having
like
a
predefined
option
struck
that
you
just
pass
over
it
is
over
pending.
I
can
solve
this
nicely
because
the
UA
can
just
start
it
to
say
like
a
bit
masked
or
something
like
that.
B
For
now
it
just
serves
as
a
hint
because
we
only
have
a
boolean
field
under
the
new
proposal,
but
having
that
hint
does
allow
like
avoiding
like,
say,
you're
doing
two
hit
tests
or
something
like
that,
and
so
our
idea
for
the
whole
continuous
events
shtick
is
to
just
have
a
simple
boolean
include
continuous,
throw
it
into
your
is
no
pending
options,
dictionary
object
and
then
yeah.
It's
really.
B
A
C
B
B
Imagine
for
the
few
cases
like
that
they
would
probably
care
about
all
types
of
continuous
events,
obviously
like
I
I'd
love
to
have
more
examples
of
cases
where
people
could
use
this
I
wouldn't
be
terribly
opposed
to
shipping
a
version
of
the
safety
out.
What
only
handles
like
discrete
UI
events,
but
sorry
did
that
answer
your
question
or
were
you
focusing
more
on
the
UI
event,
part
of
it
whoa.
D
C
C
If
somebody
comes
in
and
add
a
new
continuous
event
pop
up,
we
know,
what's
gonna
update
it,
that's
more
like
a
concern
to
me
like
that,
like
also
we're,
probably
gonna
miss
some
events
that
we
haven't
thought
of
pressure
right,
so
I
think
it's
not
ideal
to
like
try
to
come
up
with
some
sort
of
general
categorization
of
all
events.
In
this
event,
like
this
specification,
I
killed,
the
ID
I
think
I'll
be
better.
If,
if
we
read
any
such
a
concept,
define
that
in
some
other
spec
yeah.
C
Right,
oh,
like
just
come
up
with
something
that
defines
specific
subcategories
people.
Are
you
know
trying
to
use
this
API
for
right?
I
can
imagine
things
like.
Maybe
people
want
to
listen
to
just
hold
hands
and
they're
a
bunch
of
attach
events.
We
can
just
listen
for
that
or,
like
maybe
people
interested
in
Mouse
events
right,
maybe
excluding
wheel.
So
maybe
something
like
I,
don't
know
that
a
mouse
actions
or
something
like
that
right
so
like
that
Oh
Oh,
pointer
actions,
pops
yeah.
B
We
would
need
a
bit
more
depth
than
just
pointer
actions,
but
I
agreed
I
think
that,
starting
from
a
small
like
small
set
of
levers
and
get
aggregating
feedback
from
users
over
time
to
how
we
could
possibly
like
extend
the
Kaizen
blending
option,
struct
makes
a
lot
of
sense.
Yeah.
C
I
may
also
like
from
making
sure
like
this
API
is
kind
of
implement
across
the
browser.
I
think
there's
a
benefit
starting
small,
because
then
we
can
always
add
more
right,
but
I
already
have
a
small
set.
Then
it's
probably
easier
for
the
implementers
evaluate
whether,
like
you
know,
this
API
is
implementable,
so
forth.
Sure.
D
F
D
B
B
A
A
F
F
So
what
bring
us
the
context
for
this
issue?
Is
you
know,
developers?
There
are
many
many
many
use
cases
where
developers
want
some
kind
of
reliable
signal
that
a
user
might
be
about
to
leave
a
page
whether
that
means
they
are
switching
to
a
new
tab
and
they
know
for
coming
back
whether
they're
closing
the
tab
with
or
the
switching
apps
and
mobile.
F
Where
you
know
you
can
just
close
an
app
and
there's
no
opportunity
to
run
the
fire.
These
events,
and
so
visibility
change,
has
long
been
kind
of
touted
as
the
event
that
solves
this
use
case
and
we've
been
you
know,
Illya
has
been
promoting
this
event
for
a
long
time
as
I
link
in
this
blog
post
or
anything
to
one
of
his
blog
post
from
2015.
F
In
this
issue,
and
more
recently,
I've
been
working
with
a
lot
of
people
internally
at
Google,
who
are
trying
to
kind
of
have
a
solution
to
use
cases
like
this,
and
the
issue
is
that
there
are
a
bunch
of
bugs
across
many
of
the
browsers
what
this
doesn't
work
reliably
today.
I
know
that
you
know
worse,
but
I'm
not
like
just
here
to
talk
about
bugs
try
to
get
people
to
do
fix,
bugs
I
was
looking
into
it.
F
I
think
the
issue
is
not
I
mean
bar
bugs
and
they
should
be
fixed,
ideally,
but
I
think
the
issue
is
primarily
around
ambiguity
in
the
spec
and
I.
Think
part
of
the
reason
that
there
are
bugs
is
because
the
way
the
spec
is
currently
worded,
there
are
a
lot
of
cases
that
are
missed,
so
you
have
a
scroll
down
to
the
kind
of
the
chart
that
shows
like
desktop
and
mobile
yeah
main
cases
yeah,
maybe
a
little
bit
more.
F
Yes,
the
main
cases
that
we
miss
are
cases
involving
both
the
tab,
twitcher
and
the
app
switcher
on
mobile
operating
systems.
A
user
can
switch
into
the
app
switcher,
and
now
they
can
still
see
a
you
know,
a
screenshot
or
a
view
of
the
window,
but
the
problem
is
as
soon
as
the
switching
at
the
app
switcher
or
the
tab.
Switcher
they
can
press
the
X
or
swipe
away
and
in
the
page,
will
immediately
closed
and
only
Firefox
will
fire
the
visibility
change
event.
F
In
that
case,
I
suspect
that
in
iOS
there's
no
opportunity
to
fire
that
event.
At
that
point,
so
the
proposal
I
have
here
is:
wouldn't
it
make
more
sense
to
say
that
as
soon
as
you
switch
into
either
the
app
switcher
or
the
tab
switcher
that
that
is
the
point
at
which
the
page
is
you
know
effectively
in
the
background,
and
that
is
the
point
at
which
we
fire
the
visibility
change
event.
F
F
F
C
F
So,
okay
yeah,
when
you,
when
you
like
take
so
I,
tested
these
on
an
iPhone
10,
where
you
can
do
a
swipe
of
gesture
from
the
bottom
and
at
that
point
you
enter
into
the
app
switcher
I.
Can
then
you
know
swipe
sideways
to
switch
to
a
different
tab,
but
I
don't
actually
switch
to
that
EV
until
I
kind
of
press
on
the
new
app
I
can
also
swipe
up
on
any
of
the
open
applications
to
close
that
application.
C
F
C
A
We
assume
that
it's
feasible
to
do
that.
Do
you
agree
with
the
definition
because,
from
my
perspective,
the
main
problem
with
that
is
the
fact
that
we
called
that
state
hidden
rather
than
inactive
or
something
else,
because
yeah,
the
user
is
still
seeing
a
screenshot,
but
it
same
time
the
page
is
inaccurate.
So
for
all
intents
and
purposes
you
know
it
is
hidden
if
something
like,
if
JavaScript
like
I,
don't
think
that
JavaScript
runs
at
that
point,
and
you
know
there
is
no
like
the
page-
is
effectively
frozen.
So
yeah.
A
Yeah
I
think,
oh,
oh
all
those
switchers
should
trigger
the
hidden
like
if
the
user
is
clicking
the
like
clicking
on
the
tab
switcher.
The
page
should
like
the
main
page
that
they're
currently
looking
at,
should
become
hidden
or
inactive
or
whatever,
and
then
should
be
become
active
again
once
the
user
is.
You
know,
I've
chosen
not
to
move
away.
F
Yeah
to
kind
of
a
possibly
ridiculous
hypothetical,
if
on
desktop
browsers,
some
browser
was
to
implement
some
UI,
where
you
could
see
a
screenshot
of
every
open
tab.
You
have.
We
then
suddenly
have
to
say
that
now
all
those
tabs
are
visible
or
not,
it
seems
that
would
be
ridiculous
to
fire
the
visible
event
in
all
those
cases.
So
one.
E
A
A
C
Yeah
I
mean
I
kinda
agree
with
what
the
Philips
a,
which
is
that
they've,
you
know
rendering
is
not
getting
updated.
You
could
argue
that
it's
not
visible
right,
for
example,
on
the
windows,
at
least
in
some
version
of
Windows.
You
can
just
click
on
the
like
application
right
and
you
can
see
the
trivial
application,
but
then
maybe
you
wouldn't
consider
a
space
being
visible
if
that
windows
hidden.
C
F
Is
anybody
from
the
I'm
sorry
God
go
ahead?
I
wasn't
asked
if
anyone
from
Mozilla
is
on
the
call,
because
Mozilla
is
at
least
all
the
cases
that
I
could
think
of
is
firing.
The
visibility
change
event,
and
so,
if
you
want
to
make
this
change,
they
would
presumably
have
to
then
update
their
implementation.
I
don't
know
if
they
would
have
been.
F
F
I
mean
I,
guess
it
depends
on
whether
I
mean
arguably,
but
they
would
have
to
or
not.
But
if
we
change
the
definition
of
the
hidden
state
to
say
that
as
soon
as
the
page
stops
being
kind
of
fully
interactive,
then
it
becomes
hidden
so
right
now
they.
So
that
would
mean
that
you
know
on
Android
that
Firefox
mobile,
if
you
were
to
click
into
the
tabs,
which
are
our
app
switcher,
it
would
fire
the
event
as
soon
as
that
happened,
rather
than
at
the
end
of
that
interaction.
I.
C
A
B
A
A
F
And
then
there
was
another
open
issue
about
somebody
was
saying
the
hidden
event
fired.
You
could
still
see
a
page
and
sensitive
information
was
being
leaked.
We
could
clarify
that.
That's
not
the
intention
of
the
API.
The
intention
is
not
if
it
says
the
stays
hidden,
then
the
you
just
can
see
nothing.
You
know.
A
A
A
A
D
A
A
A
D
A
A
A
A
A
Guess
my
main
question
before
we
will
try
to
answer
the
question
is:
is
this
question
blocking
because
that's
to
me
it
sounds
like
the
current
spec
indicates
that
occlusion
doesn't
involve
iframes
and
iframes
just
inherent
the
state
from
their
parent
and
if
someone
wants
to
add
some
sort
of
occlusion
behavior
that
does
interact
with
iframes.
That
sounds
like
a
feature
request.
D
F
A
D
D
E
So
Yosuke
said
like
well:
okay,
if
you
just
wanted
to
show
up
in
death
tolls,
can't
you
just
use
console
about
time
and
time.
N
and
people
were
saying
like
it's.
It's
too
constrained
compared
to
use
a
timing,
L
3.
A
A
A
C
A
A
E
A
A
C
A
A
Yeah
so
I
would
tend
to
like
I
need
to
look
at
this
further,
but
I
would
tend
to
just
say
that
this
is
more
of
like
an
issue
that
should
be
open
on
the
console
spec
and
then,
if
it's
not
console,
but
something
else,
I
mean
it
still
sounds
like
something
like
the
console.
Spec
is
responsible
responsible
for
developer,
tooling
and
I'm,
assuming
that
console
logs
and
are
also
written
to
dev
tools.
So
maybe
it's
a
console
function
that
doesn't
print
the
console
which
is
I
agree.
F
To
me,
the
specific
it's
all
a
problem,
because
certain
Analects
vendors
are
recovering
all
marks
and
measures,
or
at
least
all
measures,
and
these
users
are
saying
we
want
to
have
some
of
our
tools
to
play
these
this
way.
But
then
other
tools
are
playing
this
way.
So,
let's
add
an
API
to
control
that,
but
that
doesn't
seem
like
it
seems
like
it
should
be
in
the
configuration
of
the
analytics
vendor,
not
in
the
spec
yeah.
D
A
A
A
A
C
A
C
A
A
A
C
A
B
C
A
F
This
relates
to
the
thing
we
discussed
before,
which
is
if
we
clarify
the
inspect,
that
the
hidden
state
doesn't
mean,
doesn't
necessarily
mean
the
user
can't
see
the
page.
Then
we
could
tell
us
you
do
that
like
this
is
not
a
security
feature.
They
can't
expect
that
just
because
they
just
because
the
transitions
are
hidden
and
they
can
use
it
as
a
way
to
guarantee
that
somebody
can
I
see
sensitive
information.
F
C
No
I
think
I
think
you're
missing
the
point
of
society,
so
this
issue
is
about
so
the
app
is
doing
this
thing
imagined
it
like.
If
it's
an
let's
say
like
a
banking,
app
right,
Banking,
Act
II,
who
go
to
that's
a
app
switcher.
It
could
hide
the
content
of
the
app
they're
trying
to
implement
something
similar
in
a
webpage
right
like
they
have.
D
F
C
Think
the
question
is
whether
the
spec
currently
has
an
expectation
or
not.
If
it
doesn't,
then
I
think
I
suggest
that,
like
don't
don't
let
this
thing
basically
I
think
basically
our
I'm
gonna
say
is
that
they,
the
each
the
requester,
also
like
opener
in
the
day,
ish
issues
not
implementable
in
Safari.
As
things
start,
it's
my
easiest
thing
to
say
like
as
soon
as
we
fire
visibility
hidden
like
we
don't
have
any
way
to
render
page
so
yeah.
F
C
F
Right
did
a
similar
thing,
I
think
with
a
page
Lassiter
by
API
for
the
frozen
state
that
there's
like
no
guarantees
that
all
of
these
callbacks
couldn't
borrow
things
like
that
I
think
we
could.
We
could
clarify
that
in
the
if
we
update
the
definition
of
of
hidden,
we
could
clarify
that
at
this
state
you
know
rendering
callbacks
may
not
fire
or
something.