Re: WebPerfWG call - Thursday Jan 30th @ 10am PST

Hey all,

Apologies for the late minutes publication, but travel got in the way...
The minutes
<https://docs.google.com/document/d/e/2PACX-1vRVEHQyqUAOR3f0i_b99huuR783PARUBex3S1RZYLAWrCHc0wHfseVFlhiK9r4QXH0NUs7ww8EF4627/pub>
and
video <https://www.youtube.com/watch?v=h47QOdlvo-c&feature=youtu.be> from
the last WG call are now available. Copying the minutes here for safe
keeping:

WebPerfWG call - January 30th 2019

Participants: Philippe Le Hegaret, Yoav Weiss, Philip Walton, Annie
Sullivan, Steven Bougon, Andrew Comminos, Ryosuke Niwa

Next call: Feb 13th, 10am PST
isInputPending

Andrew: Continuing from last week. Talked about the security implications
of differences between hit tests, and the approach different UAs take
towards it

Yoav: Can’t we perform hit-testing once, or mandate that both hit tests
match? Chrome security folks don’t think the information is
highly-exploitable, but blocking the race condition sounds like a better
option.

Andrew: locking event to origin may leak information in itself, The frame
that received the initial isInputPending and no event could infer the event
was dispatched to another frame

Yoav: That’s the leak in the current implementation. In the single hit-test
case, you’d get the event even in case your iframe moved. In the other
option, you’d get isInputPending but no event, in which case you know you
have an event that was supposed to arrive, but someone moved your frame.

Andrew: Is “event should have been dispatched?” cross-origin information
that we don’t want to leak

Yoav: The information “leaks” to same-origin in which the event should have
been dispatched

Andrew: depends on how you define “should have”

Yoav: Agree

AI - discuss 3 options as part of a TAG review

Ryosuke: discarding the event in case of a mismatch sounds risky.

Andrew: changes hit testing expectations, so agree

Ryosuke: what about doing hit testing once? That sounds low risk. If
anything, improves the synchronization between user click and event. Seems
preferable

Andrew: now to spec changes.

… Using DOM event types wasn’t ideal.

Initially provided a list of DOM events, because we wanted to provide UAs a
way to avoid continuous events (mouse move, etc).

… That turned out hard to spec out, because implementations don’t really
match and spec that,

… Tried to solve this problem by picking the right set of events, which
works other than a few edge cases

… Primary objective was to focus on discrete events rather than continuous

… So we need to define what is “continuous events”, and expect most users
to not be interested, but want to continue to expose this information

Philippe: there’s work that the pointer events folks do on that front. Need
to be aware of getCoalescedEvents
<https://www.google.com/url?q=https://w3c.github.io/pointerevents/%23dom-pointerevent-getcoalescedevents&sa=D&ust=1581328912653000>
/getPredictedEvents
<https://www.google.com/url?q=https://w3c.github.io/pointerevents/%23dom-pointerevent-getpredictedevents&sa=D&ust=1581328912654000>
In
Pointer Events 3.

Yoav: Also Event Timing

Andrew: working with Nicolás and want to unify the definition between this
and EventTiming.

Yoav: will also unify with other WG if makes sense

Andrew: Moving on to IDL. IDL uses an Options struct which is more
efficient to call this frequently.

… The original implementation resulted in many string comparisons so it was
expensive.

… The idea is that if you want to track continuous events you add that as a
boolean.

Yoav: Makes sense.

Ryosuke: why support continuous events at all?

Andrew: use case could be a game that reacts to mouse moves. Won’t oppose
shipping just UI events if that’s better.

Ryosuke: definition of continuous events should be in HTML or UI events
spec. Would be better to define it elsewhere. There could also be
sub-categories (e.g. touch events, mouse events).

Andrew: starting from a small set of options makes sense

Ryosuke: also need to make sure it’s implementable so it's easier to start
small.

Philippe: sounds like there’s overlap with Pointer Events

Andrew: will file an issue on GH to track that (
https://github.com/WICG/is-input-pending/issues/24
<https://www.google.com/url?q=https://github.com/WICG/is-input-pending/issues/24&sa=D&ust=1581328912662000>
)
Page Visibility and hidden

Philip: There are many use cases where developers want a reliable signal
that a user is about to leave the page (switching tabs, switching apps,
etc).

… There are a lot of situations where you’re trying to run some idle code,
which is not urgent but needs to run before the user leaves.

… Unload, pagehide and beforeunload are not reliable, especially on mobile.
Visibility change has been *the* event to solve this for a while.

… More recently I’ve been working with people at Google on that use case.
But there are a bunch of issues in different OSes and the issue is around
ambiguity in the spec, resulting in missed cases.

… So the main cases are cases involving the tab and app switchers in mobile
OSes.

… As soon as the user moves to the switcher, they can dismiss the tab or
app, and only firefox fires the event in this case.

… On iOS, it’s not clear if firing the event is at all feasible.

… So it would be easier to say that as soon as the user moves to the
switcher, the page can be considered “in the background” and
visibilitychange should fire.

… But the spec says that if a part of the page is visible, the page is
“visible”.

Some questions:

   - Do we agree that in iOS, it’s not possible to fire the event after the
   user is in the switcher?
   - If so, can we change the spec to fire the event as soon as the user
   moved to the switcher?
   - Thoughts on definition change?

Ryosuke: Confused about the distinction between switching and closing in
the switcher

Philip: Not sure what the distinction is, and why iOS does different
things. I think that when the app is dismissed, Safari can’t run.

Ryosuke: What is the difference in your testing between those cases?

Philip: Tested in iPhone X. swipe gesture from the bottom gives you the app
switcher. Then a swipe sideways switches to a different tab, swipe up
closes applications.

… So switching app is swipe from bottom then swipe sideways to pick a
different app.

… Closing app is swipe from bottom then swipe up to close the Safari app.

… So want to change the model to fire before entering the app switcher, not
after taking an action there.

Ryosuke: I think we know when we go into the app switcher, so probably
possible to change.

Philip: I believe the blur event fires so there’s opportunity to fire an
event.

Yoav: If we assume that it's feasible, would you agree with the definition?
From my perspective, the main problem is the name “hidden”, but otherwise
the page is hidden. All those switcher should trigger the hidden state.

Philip: On desktop, a browser could implement a UI that shows a screenshot
of all tabs. But it’d be ridiculous to fire events for all those tabs in
that case.

Philippe: When you say screenshot, would a video on that page play?

Philip: No

Philippe: So we’re not really seeing the viewport

Philip: I agree but need to clarify the spec. Also, do we want to change to
“active”/”inactive”?

Yoav: Won’t be able to change the names for compat, but don’t think it’s a
major source of confusion. So need to clarify the spec, and it probably
won’t trip up a lot of people

Philip: Agree

Ryosuke: Sounds reasonable, assuming it’s implementable. I agree that if
rendering is not updated, it’s not “visible”. In Windows you could see the
preview of apps, but wouldn’t consider it visible. Same in Safari’s “select
tabs” view, but it’s just screenshots.

Philip: Anyone from Mozilla on the call? They would need to change their
implementation if we change the definition, as they now fire the event
after the tab switcher action happened.

Yoav: Not on the call (between FOSSDEM and their all-hands). But we can tag
them on the GH issue.

Changing the spe sounds relatively easy, and then the question is how hard
it would be for implementations to follow.

Philip: There was another issue where someone was complaining about
information leak in the “hidden” state. We can clarify that “hidden”
doesn’t mean that the user can’t see a screenshot

Yoav: So we have agreement. Philip - would you be able to summarize the
discussion on the issue?

Philip: Yup.

Issue TriagePage Visibility

Update spec so Bikeshed can automatically pick up linkable terms
<https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/57&sa=D&ust=1581328912678000>

Philippe: Open PR on 54
<https://www.google.com/url?q=https://github.com/w3c/page-visibility/pull/54&sa=D&ust=1581328912679000>

Yoav: Last comment from Marcos says “don’t merge yet”. Should we give it
more time?

Philippe: I’ll look into it
Lack of clarity on how occlusion behavior interacts with iframes
<https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/56&sa=D&ust=1581328912681000>

Philippe: long standing issue - do we classify an iframe the same as its
parent or not.

Yoav: So if the window is occluded and that covers an entire iframe, what
should the iframe state be.

… But before concluding what we should do, is this blocking? According to
the current spec, iframes just inherit from their parent. So any occlusion
behavior that does interact with iframes sounds like a feature request.

Philippe: and in the past we said we won’t change that behavior. I’ll find
a pointer to past-issues.

Yoav: In the meantime, we can set it as a feature request and bump it to L3.

Philippe: I’d be surprised if we’d change behavior.
User TimingAllow marks and measures to be shown in developer tooling
without adding it to the performance timeline
<https://www.google.com/url?q=https://github.com/w3c/user-timing/issues/68&sa=D&ust=1581328912686000>

Yoav: Using mark and measure in a tight loop results in performance costs.

Annie: People also complained about the spamming of the perf timeline.
Console.time and timeEnd are too constrained compared to User Timing L3

Yoav: Where is the console specified?

Ryosuke: https://console.spec.whatwg.org/
<https://www.google.com/url?q=https://console.spec.whatwg.org/&sa=D&ust=1581328912688000>

Yoav: I would split the ask into 2 different parts

   1. UT implementation in Chrome has too much overhead. Chrome should fix
   it
   2. Console should enable all the things that UT enables

… But I don’t think we want a UT option to not fire user timing entries.

Annie: They don’t want it in the console, but in the performance tab

Ryosuke: still a developer tooling feature. The tab in which it shows up is
UA dependent

Yoav: Tend to say that they should send a feature request for the console
spec. Maybe they want a console function that doesn’t print to console,
which is admittedly weird

… Otherwise, the Chrome slowness is on me and I should fix it

Philip: The spamming is only a problem because some analytics vendors
collect all the entries, and they should ask them to do the filtering.

Yoav: Yup. Andy Davies commented the same on the bug. Some RUM products
support it. I’ll sum it up on the issue.
requestIdleCallbackDefine algorithm for determining whether high priority
work exists
<https://www.google.com/url?q=https://github.com/w3c/requestidlecallback/pull/88&sa=D&ust=1581328912694000>

Yoav: Since Ryosuke won’t have time to review in the near future, we can
look for other reviewers. Boris, Anne and/or Domenic come to mind.
Resource TimingThe step to queue a task to run fire a buffer full event
should specify its source
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/215&sa=D&ust=1581328912696000>

Yoav: Can we use the “performance timeline task source”

Ryosuke: Sure.

Yoav: Assigning to myself

Page Visibility (again)Switching tabs in Safari for iOS still displays the
elements that should be hidden
<https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/58&sa=D&ust=1581328912699000>

Ryosuke: After pageVisibility fires Safari never updates the rendering.

… They are updating the DOM as part of the pageVisibility event to hide
sensitive information. … But the rendering will never get updated.

Yoav: Maybe the first step would be to clarify what they meant on the
issue. How does page visibility related to rendering opportunities?

Ryosuke: Switching tabs fires the event, but rendering is not updated.
Question to the WG: Is there an expectation in the spec that rendering will
happen?

Philip: “hidden” state doesn’t mean the user can’t see the page, and is not
a security feature.

Ryosuke: Banking app can want to hide the content when going to the app
switcher.

… When the app is inactive, they want to hide that content.

… Does the spec have that expectation right now?

… It’s not implementable in Safari

Philip: doesn’t seem like it’s in violation of the spec. We need to clarify
that to set expectations.

Ryosuke: can add a note saying that there can not be rendering
opportunities after the event runs.

Philip: We could clarify that when updating the definition of hidden:
updates to rendering may not fire until the page becomes visible again

Yoav: Makes sense, don’t think we want to provide guarantees that the page
is “hidden from view” and gets rendering updates.

AI - Philip to sum up #58 as well.


On Tue, Jan 28, 2020 at 9:59 PM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Join us <https://meet.google.com/agz-fbji-spp> to talk webperf this
> Thursday!! On the agenda we have Long Task reentrency
> <https://github.com/w3c/longtasks/issues/76>, continuing the discussion
> on IsInputPending from the last call, as well as a long list of issues to
> triage.
>
> As always, the call will be recorded and posted online.
>
> See y'all there!
> Yoav
>