►
From YouTube: WebPerfWG call 2023 08 17 - EventTiming updates
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
And
this
summer,
like
with
Patricia
and
Michael,
we're
together
close
a
few
gaps
in
event,
timing
and
would
like
to
introduce
some
changes
to
this
pack.
So
today,
I'm
going
to
present
the
updates
we
have
and
any
questions
concerns
are
welcome.
At
the
end,
all
right,
let's
get
started
so
exposed
interaction
ID
to
more
events.
What
does
it
mean
so
for
folks
who
not
familiar
with
even
timing?
I'll
give
you
a
brief
context.
A
So
interaction
is
a
group
of
events
triggered
by
the
same
user
input
and
even
timing
assigned
unique
interaction
ID
to
interest
in
order
to
identify
the
user
interaction
which
triggered
the
associated
event
and,
on
the
other
hand,
IMT
as
a
metrics
capture,
the
longest
duration
of
kind
of
an
event
within
each
interaction
on
the
page
yeah.
A
A
So
here
comes
the
current
spec:
it
only
exposed
interaction,
ID
to
K
done
and
K
up
for
keyboard
related
events
and
for
any
other
type
of
events
like
key
price
or
input.
Their
interaction
ID
would
be
zero,
and
this
means
imp
won't
measure
them
since
imp
supposed
to
only
capture
the
longest
duration
of
an
event.
This
is
fine
as
long
as
the
longest
duration
lies
in
either
key
down
or
key
up.
A
However,
it
doesn't
happen
all
the
time.
So
here's
an
example:
hey
press.
There
is
a
known
and
reproducible
case
for
key
price
to
own
the
longest
duration,
whether
it's
interaction,
so
you
as
you
can
see
in
the
screenshot
get
on
the
key
up.
Duration
is
they're
all
smaller
than
key
press.
So
in
order
for
imp
to
capture
its
duration
and
correctly
reflect
the
user
responsiveness
experience,
we
want
to
include
key
press
to
be
exposed
for
interactive
ID.
A
Yeah
so
when
out
of
ime
keyboard
interactions
can
be
identified
nicely
by
each
K
down
and
Kia
player.
However,
this
is
no
longer
the
case
when,
with
ime
always
say
under
composition,
where
a
random
number
of
K
donkey
apps
can
be
dispatched,
and
the
number
is
depending
on
different
ime
user
uses
or
different
platforms.
A
Yes,
ime
is
a
input
method
editor
which,
for
example,
in
the
screenshot.
You
see
another
layer
on
top
of
the
page
and
that's
an
example
of
Chinese
ime,
which
user
using
like
English
keyboard
to
input
some
other
language
character,
for
example
like
Chinese
in
this
case,
and
that's
just
a
they're
like
editing,
method
or
choice
for
input
special
characters
yeah.
So
with
ime
like
Kiran
Kia's
numbers
can
be
random
in
this
screenshot,
only
one
key
down,
but
two
caps.
Then
how
could
we
Define
user
interaction?
A
So
now
the
input
event
becomes
special,
as
we
noticed
it
usually
has
just
one
input
event
within
each
interaction,
and
it's
also
the
key
event
associated
with
the
tax
input
onto
the
page,
thus
trigger
rendering
and
paint
which
imp
would
like
to
measure.
A
So
input
event
was
a
perfect
solution
until
we
noticed
cases
where
user
interaction
with
no
input
so
see
on
the
screenshot
here
user
stroked,
the
letter
h,
k
and
they'd
inject
the
letter
H
onto
the
ime
text
box,
but
not
the
text
logs
on
the
page,
thus
no
input
event
dispatched.
This
makes
sense.
Okay.
But
how
do
we
capture
this
type
of
interaction.
A
You
may
ask
like
it
won't
result
in
paint,
then
can't
be
imp
candidate.
Why
bother
capture
it
at
all?
Well,
we
need
capture
the
correct
number
of
interactions
on
the
page
load.
A
Imp
takes
the
98
percentile
longest
duration
at
its
score,
so
the
number
of
interactions
does
matter
so
we
can
omit
like
we
are
allowed
to
Omit
some
event
within
the
interaction,
but
we
should
never
omit.
Any
interaction
happened
on
the
page.
A
So
that's
why
we
we
find
out
the
composition.
Update
can
be
the
center
of
the
stage
where
each
user
interactions
with
ime
may
or
may
not
result
in
an
input
event,
but
there's
always
a
composition
update
event.
So
this
is
how
we're
trying
to
resolve
this
issue
is
defining
interaction
based
off
composition,
update
so
after
composition
started.
A
The
first
K
down
input
would
start
a
new
interaction
and,
after
a
composition
end.
The
first
key
up
is
the
previous
interaction.
So
there's
some
pros
and
cons
for
that.
So
as
a
prose
all
important
events
carrying
interaction,
IDs,
that's
captured
by
imp,
but
there
could
be
duplicate
events,
types
like
with
an
interaction
and-
and
sometimes
it
can
be
wild
like
in
this
screenshot.
This
is
with
a
Japanese
ime,
where
you
could
say
four
chaos
in
a
row
back
to
back,
but
they
all
comes
from
the
a
single
user
interaction.
A
All
right,
so
that's
that's
it
that's
what
we
got.
Here's
an
overview
of
the
change.
We
want
to
expose
interaction,
ID
to
keep
press
event.
We
also
wanted
to
be
exposed
to
our
input
event
and
also
K
done
K
up
clusters
under
compositions
centered
by
composition,
update.
A
If
anyone
has
any
questions,
concerns
objections
now
we
can
discuss
it.
That's
it
cool!
Thank
you.
Let
me
stop
the
recording
and
we
can
discuss.