►
From YouTube: WebPerfWG call - August 13th 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,
so
yeah
this
call
is
being
recorded
and
will
be
posted
online
and
with
that,
take
it
away.
Nick.
B
Thanks
jeff,
let's
see
so
we
have
a
couple
things
on
the
agenda
today.
First
thing
probably
talk
about
is
just
next
meeting
two
weeks
from
tonight
now
is
august,
27th
same
time
on
a
thursday.
Any
concerns
about
that
at
all.
B
Okay,
we
will
plan
on
doing
that.
For
now
we're
gonna
be
talking
about
a
couple
different
things.
We
have
page
visibility
issue
a
couple,
preload
issues,
a
couple
other
things
to
triage,
but
I
think
first,
we
have
jason
chase
here,
who's
hoping
to
talk
with
us
a
little
bit
about
third
party
origin
trials.
B
C
Sure
I'll
go
I'll,
just
present
kind
of
design,
doc
that
was
linked
from
link
from
the
minutes.
C
Okay,
that's
better
folks
can
follow
along.
So
this
came
on
the
agenda.
I
noticed
that
because
I'm
on
on
the
mailing
list,
so
I
said,
should
I
attend
and
so
that
I
thought
I
seemed
like
a
good
idea,
so
I'll
give
some
background,
but
I'll
try
and
keep
it
brief
and
mainly
leave
it
open
for
questions.
C
So
I'm
jason
chase
has
said.
I
work
on
the
chrome
team
that
supports
and
develops
origin
trials
for
context,
and
so
origin
trials
is
a
thing.
It's
been
around
a
long
time
for
those
who
aren't
familiar
super
briefly.
It's
a
way
for
chrome
to
experiment
with
features
in
a
way
that
doesn't
lock
in
and
burn
in
and
such
essentially
web
developers
sign
up.
They
get
a
token
they
put
it
on
their
website.
It
lets
them
use
a
feature
with
third-party
origin
trials.
C
So
today
the
way
it
works
is
if
I'm
I'm
a
developer
and
I
own
food.com,
I
sign
up
for
foo.com
as
an
origin
and
that
token
has
to
match
that
origin
in
order
to
enable
a
trial.
It
is
possible
today
for
third
parties
to
enable
trials
on
behalf
of
an
origin.
So,
for
example,
if
bar.com
was
a
third
party,
they
could
go
ahead
and
register
foo.com
and
because
one
of
bar.com
scripts
is
embedded
in
fu.com,
they
could
present
the
same
token
inject.
It
be
a
meta
tag
and
that
would
turn
on
the
trial.
D
Before
going
to
the
details
of
how
how
these
things
works,
could
somebody
explain
to
me
what
the
relevance
of
this
presentation
is
to
this
working.
A
Yeah,
so
the
reason
this
is
so
this
is
not
a
standard
discussion,
so
that's
a
good
point
there,
but
the
reason
I
thought
it
would
be
relevant
for
jason
to
get
feedback
from
this
group
is
that
we
had
a
lot
of
feedback
from
various
folks
here
that
are
running
third
parties,
that
the
origin,
trial
infrastructure
is
not
something
that
they
can
use
in
order
to
test
out
discussed
proposals,
so
I
thought
it
would
be
relevant
for,
for
that
conversation
to
happen
in
the
working
room.
C
Yeah,
so
I'll
just
pick
up
thanks
for
that
question,
so
that's
yeah,
exactly
we're
always
interested
to
get
feedback
on
how
we
can
make
origin
trials
more
useful
to
both
web
developers
who
are
participating
trials
and
the
folks.
It's
largely
chrome.
Now
that
are
running
trials
to
to
experiment
with
features
so
microsoft
edge
now
has
their
own
origin
trials
program.
They've
just
started
that
and
so
they're
using
the
same
infrastructure
in
chrome,
but
they
have
their
own
registration
process.
C
So
just
in
case
folks,
weren't
aware
so
going
back,
I
was
describing
how
it
worked
because
to
the
us
point:
it's
not
it's
not
easy
for
third
parties
today
that
are,
you
know,
on
a
number
of
sites
to
experiment
on
behalf
of
those
sites
right
and
so
the
goal
of
this
of
this
change
is
to
make
it
is
to
reduce
the
friction
there
so
that
third-party
sites
can
start
third-party
providers
can
experiment
across
a
range
of
sites,
for
example,
and
they
can
do
that,
basically
at
just
providing
a
token
for
their
own
for
their
own
origin
as
opposed
to
having
to
manually
sign
up.
C
You
know
one
two,
three,
ten.
Whatever
origins
and
and
provide
and
manage
all
those
tokens,
so
that's
the
idea
at
a
high
level.
The
other
thing,
too,
is
when
you
talk
about
third-party
providers
and
so
we're
talking
with
some
internally.
They
will
often
need
to
in
order
to
gather
meaningful
data.
They
might
need
to
experiment
across
a
large
number
of
origins
or
a
larger
number
of
you
know
page
hits.
Then
we
allow
by
default.
C
So
right
now
we
have
a
kind
of
0.5
percent
of
page
loads
limit
on
usage,
and
so
that's
prevent,
burn
in
and
prevent
people
relying
on
on
a
feature
you
know
from
some
folks
internally
and
whatever
you
can
imagine.
Well,
that's
too
restrictive.
You
know
if
we
need
to
be
able
to
to
experiment
across
you
know
hundreds
or
thousands
of
sites
to
get
meaningful
data.
We,
you
know,
that's
a
concern
about
bumping
into
that
limit.
C
So
the
other
aspect
of
this
kind
of
proposal
design
is
when
you
explicitly
sign
sign
up
for
the
third
party
origin
trial,
there's
different
usage
restrictions
that
would
get
applied.
That
would
allow
you
to
exceed
that
0.5
limit
and
the
one
we're
kind
of
actively
implementing
is
okay.
C
Today,
when
you
sign
up
and
get
a
token
it's
up
to
you
as
the
web
developer
to
choose
which
pages
you
serve
that
token
on
and
thus
enable
the
trial,
so
you
can
choose
if
your
volume
is
low
enough
to
enable
that
100
of
your
of
the
pages
with
third-party
origin
trials,
one
of
the
restrictions
would
be.
You
can't
do
it
on
100.
You
still
pick
which
pages
but
chrome
will
then
also
apply
like
whatever
a
five
percent
hold
back,
where
it
will
be
consistent.
C
It's
based
on
the
finch
infrastructure,
it'll
be
the
same
users,
but
those
will
never
be
able
to
participate
in
the
trial,
even
if
you
provide
the
token
so
I'll
stop
talking
there
and
that
you
know,
because
otherwise
I'll
just
ramble
on
and
if
there's
any
questions
or
comments
or
such
sorry,
one
last
thing
I'll
add
currently
today
what
I've.
What
this
this
is
all
based
on
a
third
party
script
will
inject
a
token
like
by
inserting
a
meta
tag
and
that
script
has
to
run
on
be
served
from
the
third
party
provider's
origin.
B
So
as
a
third-party
script
provider
for
impulse
and
boomerang,
we
actually
I
mean
we-
we
hit
this
issue
quite
a
bit
with
new
features
that
are
in
origin
trial.
I
remember
when
we
were
looking
at
its
input
pending
and
the
layout
stability,
api
and
javascript
self-profiling
api.
B
We
only
experimented
with
it
on
a
couple
of
our
own
internal
sites,
just
because
that's
all
we
have
the
energy
for
was.
E
B
Actively
register
it
on
those,
and
certainly
it
wasn't,
and
due
to
that,
it
wasn't
on
large
customer
sites
where
we
actually
would
have
been
able
to
gather
more
realistic
data.
Probably
so.
This
is
definitely
very
very
welcome
from
us.
It'll,
hopefully
allow
us,
with
our
customers,
permission
to
experiment
a
little
bit
more
with
some
of
these
cutting
edge
features
on
their
sites.
B
The
only
question
I
have
is
one
thing
that
I
remember
running
into
is
the
expiration
for
these
tokens
through
the
chrome
origin
trials
was
often
like
a
three
month
time
frame,
or
something
like
that
is.
Is
that
still
the
case
where
the
there
will
be
a
short
like
a
relatively
short
term
expiry,
and
the
reason
why
I
bring
that
up
is
bundling
the
token
itself
within
the
script
that
we
deliver
to
our
customers.
B
We
don't
often
quickly
refresh
that
for
our
customers
they
may
want
to
hold
on
to
the
the
one
version
that
they're
using
for
months
or
years
at
a
time.
So
we
would
need
some
other
mechanism
to
deliver
fresher
origin
tokens.
If
we
were
to
experiment
with
this
a
bit
right.
C
So
that
that
point
has
come
up
as
well,
so
by
default,
the
expiry
is
six
weeks
and
so
yeah
we've
heard
from
other
folks
that
that's
a
pain
point
like
having
to
redeploy
tokens
so
whether
it's
like
you
mentioned
or
in
some
cases
like
internally,
you
know
there's
a
lot
of
pros
like
there's
a
lot
of
gates
and
you
have
to
do
slow,
rollout
and
et
cetera,
so
separately.
C
We're
also
working
on
a
design
to
address
that
pain.
Point
where
we
can
issue
tokens
that
are
good
for,
let's
say
the
life
of
the
trial
and
instead
we'll
use
a
different.
You
know
enforcement
mechanism
to
make
sure
we
get
feedback,
so
I
mean
net
net
the
reason
for
the
six
week
expiration
was
a
to
make
sure
developers
are
engaged
and
reacting
to
changes
to
the
trial
and
also,
as
a
carrot,
stick
to
get
feedback
feedback.
Yeah.
C
B
G
There
we
go
okay,
so
my
microphone
is
working.
I
can.
I
can
chime
in
similar
to
nick's
note
on
shopify
side.
This
has
been.
I
think
I
shared
a
while
ago
that
this
was
a
problem
for
us
as
well.
Trying
to
implement
origin
trials
on
a
number
of
our
stores
at
a
with
relatively
low
effort
has
been
has
been
a
friction.
G
That's
prevented
us
from
really
using
origin
trials,
I'm
just
hearing
I'm
just
I
mean
I
went
for
six
months
of
parental
leave
and
I
feel
like
I'm
still
catching
up
on
everything,
so
this
is
just
coming
on
my
radar
and
I'm
gonna
read
through
the
the
proposal
that
you
have
here
and
really
interested
no
questions
at
this
time,
though,.
B
Also
just
kind
of
a
side
question
I
don't
know
if
ben
was
on
the
call
for
a
moment.
I
don't
actually
see
you
know,
he's
he's
still
there.
Oh
yeah
ben
is
still
there
does
firefox
or
do
any
of
the
other
browsers.
I
know
that
chrome
and
potentially
edge
are
using
similar
mechanisms.
Are
there
any
other
browsers
that
are
doing
something
similar-ish
to
be
able
to
experiment
with.
C
Not
not
that
I'm
aware
of
chromium-based
browsers
could
choose
to
enable
support
for
chrome,
origin,
trial
tokens,
but
right
now
it's
essentially
an
opt-in
right.
Every
everyone
who
uses
chromium
has
to
configure
some
code
to
say
yeah,
so
they
could
choose
to
honor
tokens
issued
by
chrome,
but
I'm
not
aware
of
anyone.
That
does,
and
I
don't
I
know
if
you
go
back
in
the
history
of
this
idea
like
there
were
folks
from
firefox
in
mozilla
who
had
been.
C
You
know,
contributed
and
such
way
back
when,
but
I'm
not
aware
that
they
have
anything
quite
like
this.
C
B
That,
okay,
any
other
thoughts
or
questions
for
jason,
while
we
have
them.
C
If,
if
you
do
you're
welcome
to
either,
I
see
some
folks
already
have
or
you're
welcome
to
comment
on
the
doc,
you
can
reach
me
chasejay,
chromium.org
and
happy
to
talk
with
folks
individually
about
what
would
or
wouldn't
work
for
them,
whether
it's
this
in
particular
or
in
trials
in
general,.
B
B
Wonderful,
so
next
thing
we're
going
to
hop
into
some
issue
triage,
I
think
for
a
couple
different
things.
What
the
first
one
is
page
visibility
issue,
59
just
paste
that
into
the
chat,
it's
a
continuation
of
what
we
were
chatting
about.
I
think
two
weeks
ago,
where
we
wanted
to
get
some
clarification
on
hit
the
hidden
case
and
whether
the
app
switcher
might
affect
the
visibility
state.
B
If
the
app
switcher
is
active.
Ryosuke
pointed
out
for
safari,
for
example,
that
if
you
have
a
video
playing
and
you
open
up
the
app
switcher,
the
video
will
keep
on
playing
within
the
switcher
itself
and
it
sounds
like
there
is
possibly
a
proposal
or
thoughts
around
maybe
having
either
a
third
state
or
another
binary
state
of
whether
the
page
is
interactive
or
not,
or
something
like
that
you
over
yesterday
did
you
want
to
make
a
case
for
either
of
those.
A
Sure
so
I
first
of
all
after
riyaska's
comment
I
tested,
and
it
turns
out
that
chrome
on
android
also
continues
to
play
videos
when,
in
this
tab,
switcher
mode
at
the
same
time
nicholas
raised
some
concerns
that
talking
about
this
internally
nicholas
raised
concerns
that
if
we
move
away
from
hidden
as
the
stage
in
which
pages
are
supposed
to
beacon
up
their
performance,
metrics
that
can
result
in
breakage,
because
people
are
look
like
trying
to
see
if
their
visibility
state
is
explicitly
hidden.
A
And
if
that
won't
be
the
case,
they
will
do
nothing
and
then
will
lose
their
tab.
A
And
that
raised
questions
as
to
whether
we
even
need
this
third
like
what
exactly
we're
expecting
developers
to
do
in
this
third
state
of,
like
the
third
preview
state,
that's
different
from
hidden,
and
if
there
is
nothing
there,
then
maybe
we
can
just
acknowledge
the
fact
that
hidden
is
a
misnomer
and
there
are
cases
where
the
tab
and
basically
redefine
it
as
semantically
non-interactive,
but
maybe
even
alias
it,
but
keep
it
hit.
A
A
But
at
the
same
time
maybe
hidden
is
a
misnomer
and
it
should
be
non-interactive.
The
visibility
state
that
we
actually
want.
D
Well,
so
I
think
you
have
to
think
about
what
the
usage
of
this
visibility
state
in
the
forest
space
right
so
there
to
me.
There
are
two
or
three
things
that
the
websites
use
it
for.
First
is
when
the
page
goes
to
visit
the
hidden
state.
I
guess
this
is
the
primary
thing
you're
thinking
of
which
is
that
that
you
save
some
states
back
to
the
server
or
record
the
fact
that
the
page
became
unvisible,
so
maybe
for
some
like
what's
called
other
provider,
doesn't
display
us?
D
Maybe
they
want
to
record
that
fact
right.
So
that's
the
one
one
case,
but
there
are
websites
that
wants
to
let's
say,
stop
the
video
or
like
stop
some
sort
of
animations
in
a
page
when
it
goes
to
hidden
state.
They
basically
want
to
do
some
sort
of
garbage
collection.
If
you
will
so
that's
the
second
case,
so
so
the
primary
reason
I
was
raising
this
concern
is
because,
if
they
want
to
do
that
kind
of
stuff,
where
they
stop
animations
and
so
forth,
they
don't
want
like.
D
We
don't
want
that
to
happen
when
just
because
user
went
to
the
absolute
right,
because
in
that
state
page
is
too
active,
user
can
still
see
it
and
everything
the
page
needs
to
continue
to
function.
At
that
moment
like
it's,
it's
not
a
thing
which
the
user
cannot
see.
User
can
fully
see
it,
and-
and
I
mean
in
there
are
cases
in
which
the
user
accidentally
getting
the
absolute
just
state
and
they
want
to
just
go
back
right.
D
A
Yeah,
I
think
there
are
some
differences
there,
but
but
that's
not
the
the
thing
is
the
reason
why
I
think
it's
important
for
us
to
do
recognize
that
different
state
is
that
the
tab
from
the
tab
sweater,
the
tab-
can
die
at
any
moment
and
therefore
we
want
the
user
to
save
state
at
that
point,
including
like
a
local
state,
for
if
the
user
did
work
as
well
as
analytic
state
and
be
connected
back
to
the
server
for,
like
also
maybe
save
work
or
analytics
or
anything
else
that
the
app
needs
to
do
before
it
is
potentially
killed.
A
A
Maybe,
but
this
is
what
we've
been
telling
developers
for
the
last.
I
don't
know
how
many
years,
because
there
is
the
unload
event,
but
it's
unreliable.
There
is
before
and
load
it's
also
unreliable,
so
we
told
developers
whenever
the
page
is
hidden.
That's
the
point
in
time
where
you
should
save
state
and
if
we
were
to
change
that,
we
have
to
take
that
into
account
and
see
how
we
avoid
breaking
sites
that
already
do
that.
At
the
same
time,
you
are
right
that.
A
Sites
should
also
know
that
you
know
they're
in
this
preview
mode
or
non-interactive
mode
where,
where
the
user
still
sees
what
what
is
happening
on
the
site,
so
they
could
continue
to
run
animations
and
videos
and
whatnot.
A
I
So
suitcase
point
was
that
this
is
kind
of
like
app
switchers
and
more
desktop
like
features
on
mobile,
like
throw
a
wrench
in
in
the
mix
here,
whereas
up
until
now,
we've
assumed
that
mobile
browsers
are
sort
of
full
screen
and
when
you
go
not
visible,
that
implies
you're
about
to
be
able
to
to
close
or
whatnot
what
happens
on
like
split
screen
mobile
platforms,
where
you
have
two
apps
open
simultaneously,
where
it's
not
does
anyone
have
experience
there
or,
like
the
tab,
isn't
in
focus,
but
on
the
other
hand,
side
you
might
be
in
the
applications
app
where
you
could
close
it
from
a
task
manager.
E
H
H
I
mean
I
think
this
goes
back
to.
We
have
visibility
and
we
have
browser
context
and
right
now
we
keep
hitting
the
visibility
thing,
but
I
feel
like
there's
unresolved
questions
about
browsing
context
still.
A
I
don't
know
that
this
is
the
case.
What
are
the
unresolved
questions.
A
That
we
have
like
the
the
app
like
the
tap
switcher
state
is
not
its
own
browsing
context.
It's
not
what
it
is.
It's
an
application
ui,
so
it's
con
like
it
contains
it
holds
all
the
browser
and
content
in
the
same
way
that
the
tab
bar
holds
all
the
browsing
contexts.
But
it's
not
that
the
inherent.
A
A
F
Yeah
I
mean
I,
I
said
it's
no
different
than
what
exist
even
before
the
mobile
became
popular,
for
example,
on
windows.
You
already
have
the
the
app
switcher
when
you
press
alt
tab
the
windows,
tab
and
that
keeps
all
the
animations
on
those
applications
running
right,
and
I
don't
think
we
ever
consider
that
as
a
hidden
state
or
anything
like
that,
at
least
for
what
I
remember.
A
So
so
the
difference
between
desktop
and
mobile
here
is
that
on
mobile
browsers
are
significantly
more
trigger,
happy
and
killing
off
tabs
and
evicting
that
memory.
A
Which
means
that
moving
to
the
hidden
state,
I
think
that
on
desktop,
I,
like
the
the
unload
events,
are
potentially
reliable.
I
don't
know
phil
correct
me
if
I'm
wrong,
but
I
would
assume
that
the
like
the
whole
the
whole
like
before
unload
and
unload
being
unreliable
is
a
mobile
thing
more
than
a
desktop
thing.
G
G
You
know,
as
chrome
has
implemented,
bf
cache
that's
been
more
apparent
than
ever
that
we
see
unload
and
before
unload
all
over
the
place.
So
if
we
were
to
choose
a
different
api,
I
think
might
not
be
the
worst
thing,
but
I
do
think
it
is
very
important
that
we
have
some
callback
that
is
reliable
across
desktop
and
mobile
and
all
browsers.
Where
that's
the
last
point,
where
you
know
you
might
not
forget
another
callback.
A
So
what
you're
suggesting
is
that
maybe
we
need
a
save
state
now
callback
that
will
be
clear
on
these
semantics
and
then
leave
hidden
and
visible
to
be
like
the
point
in
time
where
the
tab
is
actually
hidden.
So
the
preview
mode
will
not
be
hidden
until
the
user
actually
switches
tabs.
G
Well,
I
think
I
think
that
question
depends
on
whether
or
not
the
people
working
on
these
different
browsers.
Think
I
mean,
like
ryzky's
point
I
think,
is
valid,
but
then
the
question
would
be:
could
mobile
safari
reliably
fire
the
hidden
back
on
every
single
user
session?
And
if
the
answer
is
no,
then
we
need
to
pick
a
different
callback
or
we
need
to
call
it
hidden
when
you
switch
into
this
preview
mode
or
whatever,
whatever
you
know,
temporary
state
that
we
call
this
thing.
A
Yeah,
I
I
think
riyadh
correct
me
if
I'm
wrong,
but
if
I
understand
correctly,
the
question
is
whether
webkit
is
aware
of
this
change
or
not,
and
whether
the,
although
like.
A
Sure,
but
it's
a
browser
thing,
but
it's
not
the
the
bit
that
I
don't
understand
about.
The
browsing
context
argument
is
that
this
tab,
switcher,
is
not
a
web
page
or
at
least
it's
not
a
web
exposed
web
page.
So,
like
maybe
it's
implemented
as
one
in
some
browsers.
I
don't
know,
but
conceptually
it's
not
doesn't
have
to
be
a
web
page.
So
the
comfort
of
browsing
context
there
doesn't
really
apply.
It
doesn't
treat
all
the
different
tabs
as
a
child
browsing
context,
for
example,.
H
Right
but
I
get,
I
guess
I
guess
I'm
making
an
argument
here-
that
if
rep
browser
tabs
or
the
tray
was
apparent
context,
then
we'd
actually
have
semantics
for
talking
about
what
is
active
and
what
isn't
active
and
without
that
we're
getting
into
this
thing
about
like.
Is
it
hidden
or
visible,
but
we
don't
have
any
way
to
talk
about
active
and
hidden,
active
and
visible.
A
Yeah
but
at
the
same
time,
we're
not
gonna
turn
like
those
tabs
that
are
each
one
of
them
has
its
own
top
level.
Browsing
context
will
not
be
like
there's
no
concept
of
them
being
adopted
to
another
browsing
context
when
this
tab
switcher
thing
is
happening,
and
that
seems
like
a
rather
complex
machinery
that
will
have
a
lot
of
them
like
a
lot
of
implications
like
what's
the
origin
of
that
document.
H
A
I
guess
I
I'm
not
sure,
what's
the
inconsistency
that
you're,
seeing
with
visibility
other
than
the
fact
that,
yes,
it's
inconsistent
in
the
sense
that
it's
currently
implemented
in
different
points
in
time
in
different
browsers.
But
I
don't
see
what
would
prevent
us
from
you
know
achieving
consistency
without
changing
the
you
know,
without.
I
Browser
level
concept,
as
opposed
to
an
os
level
contest.
So
I
don't
know
what
safari
on
ios
how
that
works,
but
at
least
you
know,
chrome,
on
android,
you
have
the
tab
switcher,
which
is
within
the
browser
where?
Surely
you
have
some
ui
where
the
page
needs
to
be?
It
might
not
be
interactable,
but
we
we
own
that
we
have
we're
not
at
risk
of
the
os
killing
a
random
tab,
because
the
app
is
still
in
focus.
It's
the
os
level
features
it's
this.
I
This
thing
that
you
know
someone
brought
up
on
windows,
you
can
alt
tab
and
you
still
have
a
live
preview
of
the
page
and
someone
can
hit
x
to
close
that
application
from
within
there.
It's
just
not
as
common.
So
I
guess
that
pattern
hasn't
been
as
adopted
on
mobile.
The
top
level
like
expose
type
overview,
is
very
common
and
that's
the
concern,
and
so
we're
saying
as
soon
as
the
app
at
the
os
level
enters
the
switcher.
That's
when
you
need
to
save,
because
we
can't
predict-
and
it's
very
common.
A
Yeah,
that's
a
good
point.
So
basically
we
have
two
switchers
here.
J
I
A
That's
a
good
point.
I
don't
know
if
browsers
today
actually
extend
the
lifetime
of
the
document
in
order
for
it
to
save
state
but
and
yeah.
I
can
imagine
that
being
possible.
Assuming
think
xhr
is
not
a
thing
in
those
dismissal
events
which
may
be
the
case
at
some
point.
A
Okay
yeah,
so
the
question
is
whether
we're
so
assuming
that
the
os
level
issue
is
a
serious
issue.
We
need
os
level
signals
to
the
browser
that
the
os
is
now
in
the
app
switching
mode.
G
To
give
a
specific
example
on
ios,
you
can
swipe
up
like
gesture
up
and
go
into
the
app
switcher
and
if
safari
or
chrome,
or
whatever
browser
you're
using
was
in
focus
now
it'll
go
into
this
kind
of
preview
mode.
At
that
point,
you
can
swipe
up
to
close
the
app,
so
my
guess
is
when
you
swipe
up
to
close
the
app
safari
is
not
going
to
then
run
a
bunch
of
handlers,
but
maybe
I'm
wrong.
G
D
Well,
I'm
pretty
sure
the
apps
do
get
some
call
back
when
they
get
dismissed
because
they
they're
supposed
to
save
some
states
in
that
state.
D
A
So
the
adding
a
new
thing
would
potentially
help
you
fire
that
event,
like
the
save
state
event
earlier.
A
So
if
it's
just
an
issue,
if
it's
just
a
bug
and
you
can
fire
an
event
when
the
browser
is
being
dismissed
and
I
think
we
should
figure
out
the
same
like
potentially,
we
want
to
align
behaviors
here
and
android
to
do
the
same,
and
we
need
to
figure
out
whether
it's
the
same
thing
on
android.
A
But
if
that
is
like,
if
we
can
run
an
event
at
that
point
in
time,
even
if
we
have
add
restrictions
to
it,
for
example,
not
having
sync
xhr
in
the
event
or
something
along
those
lines.
That
will
make
sure
that
the
handler
is
brief.
A
Then
this
would
be
a
potentially
good
solution
for
that.
Otherwise
we
want
to
be
able
to
fire
that
safe
state
event,
whatever
we
choose
to
call
it,
what
whether
we
keep
it
as
visibility,
hidden
or
something
else
we
wanted
to
fire
earlier.
So
when
the
user
moves
to
the
potentially
risky
state
of
the
browser
being
dismissed,.
G
So
in
my
testing,
I,
I
think
your
suggestion
risky
sounds
good
next
step.
Let's
figure
out
whether
or
not
safari
could
fire
this
event
and
if
they
could,
then
that's
probably
the
right
solution,
an
android
in
my
testing.
If
you
scroll
to
the
top
of
the
bug,
I
saw
that
chrome
did
not
fire
this
event
and
when
you
would
close
the
browser
from
the
app
switcher.
G
However
firefox
mobile
did,
which
makes
me
think
that
it
would
technically
be
possible
for
chrome
to
do
it
and,
if
chrome
and
firefox
and
safari
could
all
do
it,
then
that
would
solve
the
problem
as
long
as
they
align
to
that
behavior.
A
One
is
the
like:
can
the
browser
fire
that
dismissal
event
at
that
point
in
time,
and
then,
if
that
dismissal
event,
cues
up
requests
so,
for
example,
send
beacon,
will
those
requests
actually
be
able
to
go
up
or
will
the
browser
die
before
that
and
assuming
the
answer
to
both
of
these
is
yes,
we
can
feasibly
fire
an
event
and
requests
that
this
event
will
trigger
can
get
to
the
server
in
a
reason
like
they
have
a
reasonable
window
of
time
to
get
to
the
server.
Then
this
is
yeah.
G
I
I
believe
my
test
would
track
whether
that
was
possible
by
writing
to
local
storage.
We
could
extend
the
test
to
firing
some
beacon
and
making
sure
that
a
beacon
is
received
at
some
other.
You
know
endpoint
yeah,
local
storages,
sync
right.
G
A
Yeah
yeah,
so
it
would
be
better
to
try
out
something
async
and
see
if
it
actually
makes
it
dirty.
K
You
off,
can
I
interject
something
here
sure
I
I
mean
I
I
think
it's
probably
a
great
idea
to
you
know
allow
the
the
webpage
to
save
its
state
somehow,
but
I
definitely
see
this
like
if
we,
if
we
give
such
an
event
whether
we
abuse
the
visibility
or
create
a
new
event
or
whatever
people
are
going
to
do
things
in
that
event,
and
then
they're
going
to
do
more
things
and
more
things
and
more
things,
and
at
some
point
we're
going
to
have
to
draw
a
line
and
say
nope,
you
had
your
chance.
K
G
G
They
want
to
send
it
could
cue
them
all
up
and
send
them
as
one
http
request
in
the
you
know,
the
visibility
change
event,
but
because
they're
not
sure
if
it's
going
to
happen,
they
send
them
as
10
separate
individual
events
earlier
in
the
page,
and
so
you
could
make
the
argument
that
if
the
business
event
were
reliable,
there
would
be
less
work
being
done
in
those
cases
I
mean
that's
just
a
hypothesis,
but
I
I
would
seem
to
be
reasonable.
That
would
be
the
case.
A
You
know
that
draw
a
line
on
the
bounds
of
reliability
here
and
yes,
if
you're
running
an
event,
that's
triggering
a
long
task
like
if
your
event
handler
is
triggering
a
long
task
that
goes
beyond
x,
millisecond,
it
will
get
terminated.
A
So
if
you
want
to
save
your
state,
you
have
to
do
that
rather
quickly
and
using
asynchronous
apis,
and
what
not
does
that?
Does
that
make
sense,
or
is
that
naive.
K
Yeah
that
makes
sense,
and
I
do
think
that
we
need
something
more
reliable,
but
I
think
we
need
to
also
acknowledge
that
we
are
not
going
to
get
something.
That's
perfectly
reliable.
A
Over
perfect
but
yeah,
sorry
michael.
I
I
was
just
going
to
say:
mobile
app
platforms,
have
guidelines
for
how
much
time
and
what
the
conditions
are,
and
so
at
least
we
could
borrow
some
inspiration
there
and
how
well
it's
working
for
developers.
I
just
wanted
to
say
that
it
looks
like
the
the
two
proposals
are
to
explore.
Maybe
we
could
just
fix
the
bug
and
call
hidden
reliably
so
that
we
don't
have
to
introduce
a
third
state
or
introduce
a
new,
better
signal
for
when
we
think
would
be
a
good
time
like
we
have
to
predict.
I
This
might
be
the
last
moment
before
termination,
and
so
I
would
just
say
that
it's
going
to
get
harder
and
harder
to
predict,
even
if
we
introduce
a
new
name
because
hidden
is
the
wrong
name.
I
think
this
is
going
to
continue
to
be
an
issue
because,
as
we
said
on
desktop,
it's
probably
already
a
wrong
signal
because
of
the
way
I
call
tab
and
the
way
people
terminate
is
unpredictable,
but
then
even
on,
like
tablet
platforms
or
as
mobile
platforms
become
more
capable
right.
I
Now
I
have
on
my
android,
like
split
screen,
where
I
have
chrome
in
foreground
visible,
but
the
second
bottom
up
is
the
the
applications
view
where
I
could
force
close
chrome
at
any
time
like
it
will
be
more
difficult
to
predict.
So
if
what
we're
saying
is,
let's
just
make
hidden
reliable
so
once
we
know
it
is
going
to
be
terminated,
let's
give
it
some
time
to
actually
execute
should,
should
it
really
be
the
hidden
event.
A
That's
a
good
question.
The
problem
with
yeah
the
problem
with
the
unload
and
before
unload
is
that
people
do
many.
Many
things
like
exactly
the
line
that
alex
was
talking
about
is
long
crossed
for
unload
and
before
and
load.
Maybe
we
can
revert
some
of
that
for
a
synchronous
xhr,
which
is
the
largest
culprit,
but
last
time
we
tried
that
there
was
a
lot
of
pushback
and
I
think
we
ended
up.
A
So
in
an
ideal
world
I
would
say:
probably
yes,
but
I
don't
know
if
backward
compat
will
enable
that.
E
I
No,
this
would
be
if
we
fix
the
bug
where
we
actually
know
the
os
level
switcher
like
swiped,
the
app
away
it
actually
got
closed
and
then.
A
H
I
A
I
think
it
would
be
still
good
to
figure
out
if
we
can,
if
we
can
like
basically
fix
the
current
bugs,
if
indeed
there
are
bugs
and
not
policy
changes
and
then
because
I
think
that
would
be
the
best
thing
for
backward
compatibility
rather
than
introducing
yet
another
dismissal
event,
because
we
have
a
bunch
of
them
and
it
would
be
good
to
stop
adding
more
but
yeah.
A
If
that's
not
the
case,
then
we
could
look
into
potentially
triggering
those
like
a
hidden
state
event
or
a
some
like
you
may
get
shut
down
soon
event.
Earlier.
J
Cool
well,
I
just
wanted
to
say
if
we
were
talking
about
sync
xhr
in
some
of
these
events,
that
I
believe
that
chrome
is
currently
disallowing.
Sync
xhr
on
page
dismissal,
so
on
before
unload,
unload
visibility,
change
unless
you
sign
in
to
an
origin
trial
to
get
that
back,
and
even
that
is
scheduled
to
go
away
as
of
chrome,
88,.
A
Okay,
that's
good
because
I
I
remember
that
I
remember
the
attempt,
but
I
know
that
it
got
a
lot
of
pushback.
So
I'm
happy
to
be
corrected
and
the
fact
that
it's
yeah
potentially
going.
J
Away
so
yeah,
I
I
think
the
pushback
was
being
addressed
by
the
deprecation
trial,
so
we're
giving
developers
the
opportunity
to
hold
off
for
their
origins
for
a
few
months
and
be
able
to
fix
things
so.
H
E
J
That
may
be
what's
up
as
well
as
android.
I
don't
know.
A
No,
it's
not
just
android
all
platforms,
at
least
the
initial
intent
was
for
all
platforms
yeah,
so
I
don't
see
why
they
would
have
changed
that
halfway
through.
A
D
I
think
we
already
just
disallow
sync
xhr
before
unload
and
unload.
I
don't
know
if
we
disallow
in
the
zbd
change
events,
but
I
will
point
out,
though,
though,
in
the
case
of
apps
switcher
or
any
other
way,
the
browser
getting
terminated,
whether
xhr,
sync
or
not.
Sync
is
not
that
relevant,
because
the
their
main
limitation
is
how
much
time
we
spend
sending
a
network
request
at
all.
So
I
mean
in
that
scenario,
what's
what
matters
is
the
network?
Not
not
so
much
like
where
the
javascript
continues
to
run
or
not.
A
Yeah,
basically,
even
if
it's
a
beacon
that
takes
too
long
to
be
sent
out,
it
will
get
terminated.
Equally,
is
what
you.
A
Their
relative
mobile
os's,
whether
this
is
something
that
would
be
feasible
to
do
and
if
it
would
be
what
would
be
the
time
frames
for
those
events
to
do
their
thing
before
being
terminated?
Does
that
make
sense
as
an
action
item
for
both?
Do
you
mean
by
time
frame?
A
D
K
A
Sure,
but
you
could
figure
like
it
would
be
good
to
figure
out
the
current
state
of
affairs
and
then
yeah
try
to
see
if
this
is
something
that
it's
just
if
right
now
apps
have
five
seconds
to.
A
So,
if
the
browser
has
five
seconds
to
save
states,
we
can
conclude
something
from
that
towards
the
I
don't
know
the
foreseeable
future,
assuming
that
conditions
won't
degrade
significantly
and
then
yes,
policies
would
be
able
to
change,
but
we
would
be
able
to
fix
today's
bugs,
and
you
know
worry
about
them
if
they
regress
tomorrow
versus
if
browsers
right
now
have
zero
heads
up
as
to
them
being
dismissed,
and
then
we
have
to
figure
out
a
different
way
to
resolve
this
problem.
A
Okay
sure
awesome.
Thank
you
cool
cool
yeah.
I
don't
know
if
we
have
time
for
anything
else,
if
we
kind
of
exhausted
this
session
yeah,
so
maybe
we'll
keep
the
preload
issues
for
next
time.
A
Okay,
cool
yeah,
so
not
with
that
thanks
all
and
oh
one
more
thing,
I
sent
out
a
bunch
of
calls
for
consensus
for
various
incubations
to
the
list
earlier
today.
A
Basically,
please
take
a
look
at
them.
Please
make
sure
that
your
ac
rep
takes
a
look
at
them
in
case
you
think
they
may
have
objections
and
let
us
know
because
I
think
it
would
be
great
to
adopt
them.
Those
are
all
relatively
mature
incubations
that
I
think,
would
be
good
working
crafts,
so
yeah.
Let
us
know
if
that,
if
you
have
any
objections
or
if
your
ac
rep
does.
A
And
with
that
see
you
in
a
couple
weeks.