►
From YouTube: WebPerfWG call 2021 05 12
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
this
is
being
recorded
and
will
be
posted
online,
so
hi
welcome
to
the
web
performance
working
group.
A
Today
we
have
a
special
guest.
Jonathan
mayer
is
here
to
talk
about
an
hr
time
issue
he
opened
regarding
the
monotonic
clock,
while
sleeping,
but
before
we
dive
into
that.
Just
on
the
administrative
front,
the
next
call
is
scheduled
for
may
27th,
the
same
usual
time
so
on
thursday
10
a.m.
Pst.
If
anyone
has
issues
with
that,
let
me
or
nick
know
and
we'll
see
what
we
can
do
about
that.
A
Otherwise
I
thought
of
starting
with
a
small
issue
related
to
performance
timeline
nicholas.
Do
you
want
to
discuss
that.
B
B
So
the
question
that
you
have
posed
during
the
limitation
phase
was:
is
it
confusing
that
the
account
increases
on
each
callback
in
the
sense
that
once
the
buffer
becomes
full,
every
new
entry
will
add
to
the
account
and
it
doesn't
matter
if
the
observer
was
already
there.
So
in
order
to
accurately
measure
how
many
dropped
entries
you
had,
you
would
need
to
use
the
number
from
the
first
observer
callback.
B
And
maybe
that's
confusing,
so
one
potential
solution
is
to
basically
freeze
the
number
once
it
becomes
non-zero
right
so
the
first
time
there
were
any
dropped
entries
and
that
way
you
would
kind
of.
If
it's
I
know,
if
it's
non-zero
in
the
first
callback,
then
you
know
how
many
dropped
entries
there
were
from
the
start.
If
it
becomes
non-zero
after
then,
it
doesn't
really
like
you.
You
didn't
drop
any
interest,
but
it
still
tells
you
when
the
buffer
became
full.
Basically,
which
is
kind
of
another
use
case.
B
To
know
like
does
this
buffer
actually
come
from
some
point
during
the
during
the
page
load,
so
I
was
wondering
if
people
had
thoughts
about
which
one
is
less
confusing
or
if
there's
a
better
idea.
C
So
nicholas
my
understanding
is
that
part
of
the
problem
with
anything
to
do
with
like
drop
buffers
or
clearing
buffers
with
what
we've
tried
to
do
in
the
past.
With
resource
timing,
I
think
was
there
could
be
different
consumers
of
this
api
that
could
register
observers
at
any
time
and
they
might
read
a
different
number,
and
so,
if
you
froze
it,
it
would
be
based
on
the
first
reader
that
registered.
C
Yeah,
so
that
that
seems
fine.
That
seems
consistent.
I
need
to
think
through
it
more
for
for
like
more
concrete
feedback,
but
one
idea
that
came
to
mind
as
you
were
describing
this
problem
was
for
event
counts.
We
already
have,
like
a
total
event,
count
for
things
that
are
under
threshold
for
the
like.
You
just
have
a
total
number
of
events,
even
if
you
don't
get
the
full
details,
I
wonder
if
it's
possible,
rather
than
saying
here's
the
number
of
dropped
entries.
C
If
we
could
just
have
a
total
count
and
then
you
could
keep
track
yourself
of
how
many
you've
read
and
compare
it
to
the
total,
and
then
you
can
infer
if
there
were
any
drop
like.
I
wonder
if
it
wouldn't
be
both
consistent
and
potentially
more
useful
for
other
purposes,
and
then
you
don't
have
to
deal
with
this
growing
number.
You
know
that
you
should
expect
this
number
to
be
updated
over
time,
just
throwing
that
out.
A
There
so
what
concerned
me
about,
like
the
current
api
shape,
where
the
like
the
number
keeps
growing
over
time,
is
that
people
will
be
confused
that
and
think
that,
despite
the
fact
that
they
registered
an
observer
early
on,
they
still
have
buff
entries
that
are
being
dropped.
A
Despite
that
the
fact
that
they're
actually
observing
them
and
registering
them
and
reporting
them.
So
I
I'm
wondering
if
you
know
I
nick
you're
kinda
like
nick
and
andrew,
maybe
on
the
consumer
side
like
of
the
api.
Do
you
think
that
this
is
potentially
an
issue,
or
would
you
like
which
variant
would
you
prefer
one
where
the
number
keeps
growing
or
one
where
it's
frozen
per
observer?.
D
I
I
think
I
agree
with
you
that
the
if
the
number
would
keep
growing
it
could
lead
to
other
developers
potentially
being
confused
about
it.
D
I
think
you
know,
like
those
in
the
know
or
those
that
have
brought
the
spec
very
closely
or
those
that
would
fully
understand
the
issue
could
easily
get
it
but
like
it,
you
know
it's
like
a
very
my
new
implementation
detail
that
they
would
have
to
be
to
be
aware
about,
or
we'd
have,
to
have
like
a
big
explanation
block
in
the
in
the
spec
to
make
sure
that
people
fully
crack
it
so
yeah.
I
I
kind
of
like
the
idea
of
it
being
frozen
per
observer.
D
I
guess
I
haven't
fully
thought
through
what
that
would
mean,
but
I
think
it
like
in
in
our
case
we
would
probably
only
be
reading
it
at
the
beginning
anyway,
just
to
get
a
general
sense
of
what
we
missed.
I
wouldn't
imagine
that
we'd
be
rereading
it,
but
I
could
see
somebody
in
like
developer
tools.
You
know
looking
at
their
observer,
callbacks
and
and
just
happening
to
notice
that
it's
increasing
every
time
or
something
and
that
become
being
confusing.
D
F
C
I
think
I
was
thinking
it
would
be
exposed
the
same
way.
We
could
describe
thing,
but
the
problem
fundamentally
is
like
semantically
calling
it
numb
dropped.
It's
surprising
if
that
keeps
growing
you're
like
oh,
more
dropped
like
am
I
just
not
noticing,
and
so
you
would.
I
see
where
the
confusion
would
come
from,
but
just
renaming
it
to
total
entries
or
total
count
or
whatever,
which
we
already
do
elsewhere.
C
That
is
less
unexpected.
Now,
if
that
number
keeps
growing
and
the
two
numbers
are
equivalent
because
you
have
a
fixed
buffer
size
which
you
could
read
and
you
know
the
buffer,
the
referred
amount
plus
the
num
dropped
equals
the
total,
and
that
number
does
grow.
I
think
there's
could
be
a
case
being
made
that
fixing
the
number
of
dropped
at
the
time
of
registering
the
observer
could
also
be
potentially
surprising.
In
other
cases.
C
C
So
so
I
guess
the
the
for
the
specific
use
case,
the
most
valuable
sounds
like
fixing
it
to
the
numbers
that
were
dropped
at
the
moment
of
registration.
Then
you
immediately
know
something
happened
without
the
risk
of
confusion.
B
Right,
then,
would
we
freeze
it
at
zero?
If
the
observer
was
just
registered,
that's
enough,
or
would
it
be
useful
to
have
basically
a
rough
estimate
of
when
the
buffer
becomes
full
by
the
number
becoming
non-zero
that
one
yeah,
I'm
not
sure
if
it's
potentially
confusing
that
it
just
suddenly
becomes
non-zero
and
then
freezes.
D
B
Right:
okay,
because
I
remember
yeah,
did
you
have
another
proposal
that
wouldn't
solve
that
case?
Because
if
we're
not
planning
to
solve
that
use
case-
and
we
can
do
the
oh
yeah,
just
like
a
following
method
in
performance
right
like
like
what.
A
Yeah,
theoretically,
we
could
also
add
a
method
on
the
performance
object,
saying
like
get
dropped,
get
number
of
dropped
entries
per
like
for
each
type
and
decouple
that
entirely
from
performance
observer,
but
that
would
yeah.
That
would
mean
that
we
don't
get
the
signal
of
when
the
buffer
becomes
full.
B
Yeah,
my
main
worry
is
that
it
becomes
really
hard
to
know
exactly
when
you
have
to
query
the
numbers
to
ensure
that
you're
not
missing
the
buffered
entries.
So
that's
why
it's
nice
to
have
it
coupled
in
the
observer,
where
you
know
the
browser's,
it's
the
browser's
responsibility
to
make
sure
that
the
number
is
correctly
computed
so
that,
if
you
drop
entries,
the
number
reflects
that
right,
whereas
the
poly
method
it's
a
little
well,
it
depends
how
you
do
it,
but
yeah
it's
a
little
trickier.
D
This
po,
it's
useful
for
like,
for
example,
for
rom,
like
let's
say
it
was
resource
timing.
It
would
allow
us
to
know
how
full
the
buffer
should
have
been
by
the
time
we
got
there,
which
could
give
guidance
to
the
page
to
increase
the
buffer
or
something
like
that
or
you
know
even
for
non
things
like
resource
timing.
D
If
the
you
know
you
missed
a
thousand
entries
that
may
convince
the
person,
including
the
analytics,
to
include
it
earlier
in
the
page,
the
script
earlier
on
the
page
or
register
the
observers
earlier,
rather
than
miss
that
whole
wide
swath
of
entries.
So
I
I
do
find
value
in
knowing
the.
A
Yeah,
so
what
I'm
hearing
is
that
there's
general
support
for
or
freezing
the
value
more
than
leaving
it,
as
is.
A
A
The
hurdle
here
is
that
we
like
in
terms
of
shipping,
this
is
more
or
less
ready
to
ship
in
chromium,
but
it
would
be
a
shame
to
ship
something
and
then
realize
that
we
shipped
the
wrong
thing.
So
I'm
curious
as
to
what
we
could
like
do
on
that
front.
To
have
more
confidence,
maybe.
A
D
And
I
I
guess
the
thing
like
overall,
like
the
value
that
this
brings
is
immediate,
with
knowing
the
number
of
dropped
entries
is
great
and
the
like.
Just
the
ergonomics
around
whether
you
might
be
confused
about
you
know
it
increasing
or
not,
like,
I
think,
are
smaller
than
the
value
that
it
brings
just
knowing
that
data,
but
yeah
definitely
think
through
see.
If
there's
anything
else,
I
can
think
of
why
we
wouldn't
want
to
do
it,
but
yeah.
A
A
Okay,
so
next
up
should
we,
I
don't
know
if
we
should
maybe.
A
Nicholas
for
the
event
timing-
one-
I
just
don't
want
to
keep
jonathan
as
he's
sure
he
can
go
first.
A
Okay,
so
we
are
talking
about
hr
time
115.
Maybe
I
can
just
send.
A
So
jonathan,
do
you
want
to
talk
through
the
issue.
H
H
This
quickly
became
a
very
deep
rabbit
hole
involving
the
history
of
the
spec
and
browser
implementations
of
the
spec
browser,
clock,
implementations,
os
clock,
apis
and
eventually,
hardware
clocks
on
x86
and
arm.
I'm
happy
to
talk
about
any
of
that
as
helpful,
but
I'll
try
to
sort
of
stay
at
a
high
level
of
the
stack.
So
there
are
four
suggestions
I
made
for
possible
revisions
to
the
hr
time.
Spec.
H
All
of
the
suggestions
are,
I
think-
or
at
least
I
hope
are-
are
very
consistent
with
the
intent
of
the
spec.
The
first
is
to
clarify
what
behavior
should
be
during
system
sleep.
There
is
prior
discussion
of
that.
It
seemed
like
there
was
consensus
on
that,
and
so
that
would
just
be
a
clarification
in
the
current
text
of
what
that
behavior
should
be.
H
The
second
suggestion
I
had
was
taking
what
is
currently
an
informative
note,
I'll
be
an
informative
note,
with
a
should
in
it,
as
nicholas
noted
and
turning
that
into
normative
language
and
the
reason
to
turn
this.
The
sleeping
or
suspended
suspending
behavior
into
a
normative
note
is
that's
needed
to
implement
the
goal
of
the
spec
that
you
can
compare
monotonic
timestamps
across
globals
right.
If
you
have
you,
know
the
the
clocks
sleeping
or
suspended
on
some
globals
at
times
it's
not
on
others.
H
Those
clocks
are
going
to
go
out
of
sync,
and
so
you
can't
compare
the
clocks.
So
that's
the
second
suggestion.
The
third
suggestion
I'm
actually
going
to
flip
to
to
deal
with
last,
because
I
think
it's
the
most
complicated.
So
let
me
do
what
is
in
the
issue,
the
fourth
suggestion
and
then
I'll
do
the
third
submission.
H
The
fourth
suggestion
is
just
a
terminology
suggestion
that
the
way
the
term
clock
skew
is
used
in
the
spec
currently
is
kind
of
different
from
how
that
term
is
usually
used
in
computer
science
or
electrical
engineering,
and
so
I
thought
just
for
clarity.
It
might
be
useful
to
use
a
different
term,
so
the
the
last
suggestion
I
had,
which
is
the
the
third
in
the
spec,
is
clarifying
the
semantics
of
what
you
get
when
you
add
performance
that
time,
origin
with
performance.now.
H
H
The
user
can
just
go
and
change
it,
but
there
are
some
useful
properties
that
could
be
defined
into
the
semantics
of
adding
those
two
values
and,
in
fact,
if
I
understand
correctly
browsers,
actually
already
have
implemented
that
or
close
to
it,
with
the
changes
that
I
suggested
elsewhere,
and
so
it
would
really
be
reflecting
semantics
that
browsers
already
provide,
rather
than
change
in
the
semantics
of
the
addition
of
those
two
values
anyway,
I'll
stop
there.
H
I'm
happy
again
to
answer
questions
about
any
of
this
and,
of
course
you
guys
are
the
experts.
So
I
defer
to
your
judgment
about
how
to
address
these
things.
A
So
I
first
of
all
I
wanted
to
say
thank
you
so
much
for
the
issue
and
it's
like
it
is
a
great
issue,
well
thought
out
and
well
articulated.
So
thank
you
for
that.
Also,
thank
you
for
the
last
bit
that
you
added
about
various
os's
and
their
different
clock,
behaviors,
which
I
think
would
be
useful
for
implementers
that
will
tackle
this.
A
I
think
that
the
suggestions
for
clarifying
what
we
do
when,
like
in
sleep
mode,
moving
that
current
note
and
make
it
the
normative
should
like
both
of
those
make
sense
and
yeah
and
changing
the
terminology
for
clock
skew.
A
Similarly,
I
think
we
can
align
on
whatever
the
rest
of
the
industry
uses
and
I'd
be
happy
to
like
take
suggestions
on
that
front
on
what
term
we
should
be
using
instead
and
then
on
the
semantics
front,
I'm
generally
supportive,
but
I
wonder
if
this
is
like.
A
I
wonder
if
this
is
testable
in
some
way
like
similarly
also
for
sleep,
I
don't
think
that
we
can
like.
We
can't
have
web
platform
tests
for
what
happens
when
the
user
goes
to
sleep
halfway
through
and
for
the
semantics.
We
could
have
various
comparisons,
for
you
know
those
timestamps
compared
to
date.now,
but
we
cannot
enforce
like
users
changing
their
clocks
or
things
along
those
lines.
A
A
F
B
The
only
problem
I
see
is
that
most
clocks
seem
to
be
not
behaving
properly
during
sleep
according
to
the
table,
so.
B
The
the
concern
is
that
if
we
change
like
we
can
try
to
change
the
clocks,
but
that's
probably
a
massive
effort.
If
the
clocks
being
used
also
report
internal
metrics,
at
least
that's
the
case
for
chrome,
so
that's
potentially
potentially
could
risk
some
breakage,
especially
since
it
requires
just
altogether
changing
the
clock.
If
I
understand
correctly
right
because
the
same
cloud
is
not
gonna
just
suddenly
start
behaving
properly
so.
A
That
internal
metrics
are
somehow
like
relying
on
the
fact
that
the
freezing
behavior
is
the
way
that
it
is
right
now
or
do
you.
C
B
On
it,
I,
I
might
just
anticipate
some
metrics
to
shift
in
unexpected
ways,
in
particular
for
high
percentiles,
because
suddenly
sleeps
count
as
long
portions
of
time.
Instead
of
no
portion
of
time,
which
is
the
contrary
to
what
most
metrics
would
want.
H
So
a
thought
on
how
this
might
be
made
easier
for
implementers
that
occurred
to
me
and
previously
occurred
to
someone
working
on
chrome.
What
was,
rather
than
changing,
the
current
underlying
browser
clock,
implementations,
adding
another
clock
that
just
has
well-defined
behavior
and
the
idea
being
for
legacy
users
of
the
current
clock.
The
current
clock
stays
in
place
document
what
it
does
on
different
platforms
and
then
for
users
of
the
browser
clock
that
want
a
guaranteed
behavior
during
sleep
or
not
during
sleep.
H
They
could
use
one
of
the
clocks
that
has
those
better
defined
behaviors,
there's
actually
a
whole
proposal
that
someone
on
the
chrome
team
put
together
to
do
that
very
thing
in
part
to
address
this
issue,
and
firefox
actually
already
has
a
version
of
that
in
place.
So
there
may
be
a
less
painful
transition
available
if
switching
the
underlying
clock
were
painful.
A
That
would
have
a
smoother
migration
process,
I'm
not
sure
that
lowers
complexity,
but
in
terms
of
having
to
maintain
two
clocks
and
the
confusion
that
would
arise
from
that.
But.
A
E
A
Could
be
a
path
forward?
Do
you
you
mentioned
that.
A
That,
like
benjamin
sean,
do
you
know
what
the
situation
is
for
mozilla
like
with
firefox
you
already
like
how
bad
of
the
problem
is
it
for
firefox
to
to
align
with
that
proposal?.
G
A
No,
so
there
is
no
that
this
proposal
doesn't
suggest
an
api
change.
It
just
suggests
to
clarify
that
the
semantics
of
performance.now
will
guarantee
or
should
is
not
a
guarantee,
but
still
it
would
say
that
it
should,
for
example,
not
freeze
when
the
tab
is
throttled
or
frozen,
or
the
system
is
asleep,
so
the
clock
kept
sticking
when
any
of
those
things
happen.
G
A
As
opposed
to
not
doing
that,
which
is
the
current
behavior,
apparently
in
firefox
on
linux
and
android,
but
you
all
are
doing
a
better
job
on
windows
and
mac
compared
to
chromium,
which
is
only
doing
that
on
windows
and
safari
is
not
doing
that.
B
C
H
Yeah,
so
let
me
maybe
spell
this
out
a
little
more
in
terms
of
how
os's
tend
to
deal
with
it
and
then
how
chrome
and
firefox
currently
deal
with
it.
So
os's
tend
to
provide
multiple
clock
apis
that
vary
along
at
least
two
axes.
Monotonic
clock
apis,
I
should
say
one
is:
does
the
clock
tick
during
system
sleep
or
not,
and
the
second
is,
is
the
clock
subject
to
monotonic
adjustments?
H
So,
for
example,
your
ntp
client
might
figure
out
that,
like
the
physical
oscillator
in
the
clock,
is
off
a
little
bit?
Are
you
allowed
to
incorporate
that
into
your
clock
logic
or
not
right
that
that's
the
kind
of
logic
we
could
turn
on
or
off
in
some
of
these
apis,
so
that
that's
what
os
is
offer
with
respect
to
what
browsers
support
in
chrome?
There
is
currently
one
monotonic
clock
implementation
that
has
this
inconsistency
across
platforms.
H
Firefox
actually
has,
depending
on
how
you
count
two
to
three
implementations
that
are
used
in
different
places.
The
main
implementation
is
much
like
the
chrome
one
and
similarly
has
some
varying
behavior
across
platforms,
but
there
are
other
implementations
actually
already
in
place
in
firefox,
at
least
one
of
which
specifically
gives
you
the
option
of
calling
the
api
with
or
without
sleep
included.
H
G
Jonathan,
what
would
so
you're
saying,
I
guess
for
me,
I
would
rather
see
this
fully
specified
with
both
options,
where
you
can
call
monotonic
that
sleeps
and
monotonic
that
doesn't
sleep
and
or
with
adjustments.
G
A
A
G
A
B
So
I
guess,
if
I
recall
correctly,
we
decided
that
sleep
needs
to
tick
because,
like
what
was
the
reason
that
we
decided
like
we
needed
to
take
durian
sleep,
I
remember
we
did
discuss
this,
but
I'm
a
little
confused
right
now.
What
the
rationale.
B
A
B
B
I
don't
know
like.
Obviously,
if,
if
it's
possible
for
like
the
clubs
to
be
frozen
for
one
frame
versus
another
frame,
then
that
would
be
pretty
bad
right
because,
like
you
mentioned,
that
would
cause
it
to
be
impossible
to
compare
the
timestamps
across
the
different
pages
or
frame
space.
But
if
it's
not
the
case,
then
it's
like
it's
harder
for
me
to
see
the
the
main.
A
A
Yeah,
what
didn't
really
discuss
the
the
entire
system
is,
at
sleep
mode
case,
from
the
fact
that
this
was
brought
up
as
part
of
the
background
tab
freezing
implementation.
I
suspect
that
this
was
a
real
implementation
concern.
H
So
to
answer
nicholas's
question
about:
could
you
do
this
across
web
pages
running
on
different
threads
and
processes,
and
so
on?
Yes,
so
the
way
the
spec
is
currently
drafted,
the
issue
of
frozen
tags
is
combined
with
the
issue
of
sleep.
You
could
have
a
spec
that
says
you
can't
stop
this
from
ticking
when
a
tab
is
frozen,
but
you
can
stop
it
from
ticking
when
the
system
is
asleep
and
you
could
use
the
operating
system
clock
api
for
a
monotonic
clock
that
doesn't
tick
during
sleep
to
implement
that.
H
I
think
it
might
be
kind
of
counterintuitive
that
you
have
one
guarantee
around
frozen
tabs,
but
a
different
guarantee
around
system
sleep-
I
you
know,
I
think,
there's
probably
a
reason
you
guys
considered
those
issues
together
last
time
around,
and
I
think
there
probably
is
some
issue
of
implementer
expectation
right.
You
know
so
folks
are
really
familiar
with
date.now.
That
obviously
ticks
during
sleep.
If
performance.now
had
the
opposite
behavior
that
might
be
pretty
counter-intuitive
for
for
some
implementers.
H
All
right,
so
I
think
at
least
one
one
group
of
people
who
thought
they
would
be
pretty
close
to
in
sync
where
it
was
my
research
group.
We
were
kind
of
surprised
by
this
behavior,
which
is
what
led
us
down
the
rabbit
hole
yeah.
I
think
the
at
least
for
us.
There
was
an
expectation
when
we
started
using
the
api
that
performance
that
time,
origin
plus
performance.
That
now
would
barring
a
clock
change.
H
You
know
the
user
goes
in
and
changes
the
clock
b,
pretty
much
the
same
as
date.now,
not
necessarily
identical
for
reasons
I
touch
on
on
the
issue,
but
but
pretty
close,
and
you
know
that
that
clearly
isn't
the
case,
and
I
think
there
are
good
use
cases
for
that
right.
You
might
want
a
timer
that
is
both
monotonic
and
roughly
approximates
real
world
time.
If
you
assume
on
browser,
startup
real-world
time
is
about
right.
Those
are
the
semantics
we
were
relying
on.
H
H
A
I
think
it
makes
sense
for
us
to
be
able
to
account
for
periods
of
time
where
the
tab
was
frozen
or
the
system
was
asleep
and
not
pretend
like
you
know
it
just
didn't
happen,
and
events
of
user
changing
their
clock
are
things
that
yeah.
That
would
cause
a
drift
between
date.now
and
performs
that
now,
but
it
would
be
good
if,
barring
that
they
would
be
more
or
less
aligned
in
terms
of
the
underlying
like
the
underlying
time
would
be
the
same
time
in
a
way.
A
I
don't
know
if
there's
a
like
going
back
to
benjamin's
point.
In
my
view,
there's
no,
like
I
don't
see
a
strong
use
case
to
exposing
like
the
ability
to
pick
the
clock
to
web
developers
so
that
they
can.
You
know.
A
H
H
Just
to
add
a
layer
of
complexity
here,
if
you
wanted
to
implement
that
which,
in
a
spec
which
you
could
right,
you
could
write
a
spec
that
gave
options
like
that
in
the
same
way
operating
system,
clock
api
is
already
given
options
like
that,
in
addition
to
you
changing
performance
at
now
and
every
time
every
place
that's
used,
you
would
also
potentially
have
to
look
at
time,
origin
time
stamps
on
events
etc,
because
you're
not
you'd,
have
two
separate
monotonic
clocks.
H
So
you'd
have
to
track
all
that
activity
across
both
of
the
monatomic
clocks,
which
seems
like
a
lot
to
deal
with.
H
G
A
A
A
A
Look,
this
is
about
providing
like
some
signal
of
the
backgrounded
status
and
potentially
like
when
tabs
were
backgrounded
or
not,
and
we
had
a
whole
discussion
around
the
disability
observers.
A
It's
true
that
if
the
clock
stops
when
the
tab
is
invisible,
that
would
skew
a
lot
of
those
like.
I
think
it
would
have
an
impact
on
the
discussion
around
disability
observers,
which
is,
I
don't
know
nicholas.
This
is
currently
on
hold
right
or.
B
We
haven't
gotten
on
the
same
page
about
that,
yet
I
guess
because
there's
the
question
about
pre-rendering
and
how
it
fits
into
that,
but
so
so
yeah.
I
guess
this
made.
You
think
that
the
one
potential
reason
you
would
want
a
clock
that
frozen
sleep
is
that
you're
just
measuring
a
time
delta
between
two
events
and
the
work
just
freezes.
B
When
the
system
goes
to
sleep,
then
it
just
creates
the
potential
for
that
duration
to
be
super
long
for
no
for
no
good
reason.
Unless
you
explicitly
are
looking
out
for
oh,
the
the
tap
froze,
which
is
not
really
something
people
generally
do.
I
think
unless
they
actually
do
use
the
hidden
state.
Actually
I
don't
know
if
hidden
works
all
the
time
when
you
freeze,
okay,
when
you
go
to
sleep
like
if
you,
if
you're
visible
and
you
go
to
sleep,
I
think
it
doesn't,
it
doesn't
trigger
hidden
state.
B
So
it's
even
worse
so
yeah
that
that
would
be
a
problem.
A
Yeah,
there
are
also
no
guarantees
that
visibility
and,
like
you
know,
a
tab,
can
be
frozen
after
a
certain
time
out,
based
on
the
implementation
or
other
heuristics
and
yeah
there's
a
bunch
of
like
there
are
no
strong
guarantees
on
that
front.
Okay,
so.
G
It's
not
really
concerned.
I
just
felt
like
these.
There
was,
if
there's
a
way
to
get
these
clarifications
into
hr
time
and
fix
some
of
these
other
issues
which
are
may
or
may
not
be
related
about
like
how
do
we
count
time
on
frozen
things?
Then
we
should
take
that
this
opportunity
to
try
and
make
sure
it
fits
for
for
both.
That's
that's
my
plea.
H
A
Yeah,
but
right
now
we
can
like
the
current
situation
is
that
we
can't
really
rely
on
it
because
it's
different
on
different
platforms
in
different
browsers.
But
what
I
would
expect
as
a
solution
to
this
problem
is
to
a
lot
like
make
sure
that
we
report
timestamps
for
the
time
spent
in
sleep
and
at
the
same
time,
have
some
sort
of
like
this
tab
was
frozen
observer
or
you
know
some
indication
after
the
fact.
A
So
when
the
tab
goes
back
from
being
asleep
it
we
have
some
entry
or
some
indication
that
this
happened,
and
that
would
enable
people
to
account
for
that
lost
time.
So
they
will
know
that,
has
it
left
and
we're
getting.
G
Somewhere
so
you're
saying,
like
add
a
frozen
time
to
performance
entries,
maybe
yeah
or
whatever
dvd
yeah,
but
like
mark
mark
that
that
gap
somewhere
in
in
the
entry
timeline,
I
would
I
would
be
up
for
that.
I
think
that
sounds
like
a
good
approach.
A
A
Like
basically
yeah
we
we
have
made
that
agreement
in
the
past.
We
just
need
to
do
the
leg
work
to
implement
that
and
yeah
the
appetite
for
that,
I
think,
depends
on
the
technical
complexity
for
yeah,
which,
at
least
on
like
the
underlying
tone
from
nicholas,
is
that
it
could
get
very
complex,
so
it
will
require
some
more
research.
I'm
guessing
is
that
nikolas.
Is
that
a
fair
statement.
B
Sure
yeah
I
mean
there's
the
duck
written
by
someone.
I
don't
know
if
they
ever
followed
up,
so
we
could
talk
to
them
right
because
it's
pretty
related,
and
so,
but
I
I
think
it's
it's
good
to
try
to
align
at
least
because
right
now
we
all
have
different
behaviors
just
depending
on.
What's
the
convenient
thing
to
do
in
each
os,
I
guess
and
that's
kind
of
not
ideal.
H
While
on
the
subject
of
differing
behaviors,
I
appreciate
you
all
that
already
been
very
generous
with
your
time.
I
just
wanted
to
briefly
mention
that
there
was
another
deviation
from
the
spec.
I
noticed
in
chrome
and
firefox.
I
don't
want
to
go
too
far
into
it,
because
I
think
it's
a
pretty
clear
difference
from
the
spec
and
I
think
it's
actually
much
easier
to
fix,
and
that
is
that
the
way
time
origin
is
set
currently
in
chrome
and
firefox
is
a
bit
different
from
the
spec
in
chrome.
H
Each
time,
origin
is
actually
synced
to
the
system
clock
instead
of
from
a
shared
monotonic
clock
and
in
firefox
on
a
per
process
basis
time.
Origin
is
set
off
of
the
system
clock
rather
than
a
a
shared
monotonic
clock
again,
I
think
much
easier
to
fix,
but
I
wanted
to
mention
it
just
so
folks
were
aware
of
it.
H
I
I've
already
filed
issues
on
the
chrome
and
firefox
bug
trackers.
If
there's
something
I
should
file
with
w3c
folks,
I'm
happy
to
do
that
too.
G
Are
we
keeping
track
of
this
in
the
hr
time
bug
that
you
opened
and,
if
so,
maybe
just
to
add
a
little
short
sentence
that
says
this
is
also
an
issue
happy
to
do.
Yeah.
A
A
Cool
yeah
so.
A
Yeah,
thank
you
so
much.
I
think
that
we're
all
in
agreement
that
it
would
be
great
to
have
that
happen
and
then
the
question
like
the
main
remaining
question
is:
how
do
we
get
there.
G
I
just
want
to
say
I
also
appreciate
jonathan
your
attempts
to
normalize
what
skew
means
across
various
cs
disciplines,
so
I
really
appreciate,
like
kind
of
meeting
what
we
say
and
saying
what
we
mean.
I
appreciate
that
thanks.
A
Yeah
on
that
front,
do
you
have
proposals
for
what
other
terms
we
should
be
using?
I
don't
know
if
there
is
one
issue.
H
I
thought
adjustment
was
perfectly
fine,
as
a
in
neutral
term.
I
think
giving
examples
of
what's
permitted
and
what's
not
permitted
would
really
help
clarify
for
implementers,
namely
anything.
That's
non
monotonic
not
permitted
anything
that
is
big,
that
is
sort
of
subjective,
but
big,
not
permitted,
and
then
anything
that
is
monotonic
and
then
either
small
or
gradual,
such
as
oscillator
adjustments
or
clock.
Skew
would
be
permitted
and
then
call
of
day
and
just
not
use
the
term
skew.
H
D
H
A
Yeah,
that
seems
like
something
that
would
be
useful
as
a
separate
document.
Potentially,
although
yeah
I
yeah,
I
haven't
seen
other
like
any
other
presidents
of
you
know,
including
implementation
hints
as
a
spec
note,
but
it's
definitely
like
the
the
issue
itself
that
you,
like
the
that
you
outline
all
the
different
options.
A
That
is
super
useful,
okay,
cool,
and
I
think
we
we
covered
that
at
the
same
time
like
we
have
two
minutes
left,
which
I
don't
think
would
be
enough
to
start
discussing
any
of
the
other
issues.