Re: WebPerfWG call - August 13 @ 10am PT / 1pm ET

Minutes from this meeting are here:


Nic Jansma, Yoav Weiss, Ian Clelland, Noam Helfman, Ryosuke Niwa, Alex
Christensen, Jason Chase, Thomas Kelly, Nicolas Pena, Philip Walton, Chris
Harrleson, Sean Feng, Benjamin De Kosnik, Michal Mocny
Next Meeting - August 27th @ 11am PST / 2pm ESTMinutesIssuesThird-Party
Origin Trials

Jason: Origin Trials are a way for Chrome to test features without baking
them in.

… Developers can sign up for a token and enable trials on their origin.

… 3Ps can enable trials for their customers, but have to register a token
for them.

Ryosuke: Why discuss on the WG?

Yoav: This is not a standards discussion, but this is to enable future
proposals to use this infrastructure with 3Ps that are in the group.

Jason: Also, Edge now also have their own OT framework.

… We want 3Ps to not have to manage tokens for their customers, because it
can be cumbersome.

… Also, 3P risk triggering too much traffic to the trial. Explicit 3p
signup enables us to avoid the traffic limit.

… In that case, Chrome would limit rate across those origins instead of
allowing up to 100% of users on one origin enable the feature.

… Based on a 3P script that injects a meta tag, that must run on the 3P

… Any questions?

Nic: With mPulse and Boomerang, we hit that quite a bit. Only experimented
so far on internal sites. Want to enable large customer sites to gather
more data. So would love this.

… The expiration for tokens is 3 month. Is that something that will remain
the same. If we’re bundling the token in the snippet, that can be stale.
Need a mechanism to deliver fresh tokens.

Jason: This has come up. Expiration is 6 weeks. Working on a design that
will enable tokens for the life of the trial.

… The reason for the 6 weeks expiration was to enforce feedback.

Nic: Otherwise, sounds great from a 3P perspective

Thomas: For shopify, this was a problem for us as well. Will read through
the proposal and provide feedback.

Nic: Other browsers using similar mechanisms to enable experiments?

Jason: Not that I’m aware of. Chromiums can enable support for Chrome OTs.

… Mozilla contributed to the idea historically, but not aware of them

Benjamin: Confirmed

Ryosuke: No trials for Safari

Jason: Feel free to reach out with questions
page-visibility 59 - Do we need a preview/non-interactive state?

Nic: Wanted clarification on the hidden case, and whether app switcher may
affect that.

... Ryosuke pointed out that in Safari videos continue to play.

Yoav: After Ryosuke's comment, I tested and Chrome on Android continues to
play videos when in the app switcher mode.

... Nicolas raised some concerns if we moved away from "hidden" as the
state that customers should use, it could result in breakage for sites that
depend on it.

... What would be in this third state that's different from hidden?  Maybe
"hidden" is a misnomer here.

... "noninteractive" is really the visibility state we'd want

Ryosuke: What is the usage of visibility state in the first place?  2 or 3
things: First is when a page goes to hidden state, state is saved back to

... Second is websites want to stop video or animations on page when going
into hidden state.  If they want to do things where they stop animation.

... User can still see it.  It would be disruptive if in the tab switcher
the video stopped everything, then when they came back to it immediately it
has to restart everything.

... Compare to OS window state, it just lost the focus, we don't say it's

Yoav: Why it is important for us to recognize a different state, is that
from a tab switcher the tab can die at any moment, so the app may want to
save state.

Ryosuke: That to me isn't visibility, it's another state

Yoav: This is what we've told users to hook into for years -- whenever the
page is hidden, that's the time to save state.  If we were to change it,
we'd have to figure out how to avoid breaking sites that look into that.

... Sites should also know they're in this preview or non-interacive mode
where the user can still see what's going on in the site, so it should
still keep videos playing or run animations/etc.

Michal: So far we've been talking about full-screen mobile browsers where
only one app is in focus, but what happens with split-screen mobile
platforms, where you have 2 apps active?

Ben: I think this goes back to we have visibility and we have browser
context, but I think there's unresolved questions around browsing context.

... Do we need a third visibility state for tab switchers and stuff?

Yoav: Tab switcher state isn't its own browsing context, it's an
application construct

Ryosuke: The analogy on the Mac is that you have a full-screen app and you
go to Expose where you have multiple apps on the computer.  I'm not sure if
Safari even gets the notification when it goes to app switcher.  It's an
OS-level feature where the user sees a list of apps running.

Noam: Similar to Windows alt-tab switcher, it keeps animations on all of
those tabs running.  We don't consider that a hidden state or anything.

Yoav: One of the big differences on mobile is that browsers are a lot more
aggressive on killing tabs when switching.  On mobile unload events should
be a lot more reliable.

Philip: The main thing is there needs to be a reliable callback when that
gets called on all platforms, unlike unload or beforeunload.

... I agree visibility doesn't always follow that model, but we do have
"hidden" already.

... We've been promoting visibility as the last reliable mechanism.

... I do think it's important we have something that's reliable across all
browsers and desktop/mobile, where that's the last point you'll get a

Yoav: Do we need a "Save State Now" callback that would be clear on those
semantics and leave hidden/visible where the point in time where the tab is
actually hidden?  So the preview mode won't be hidden until it's another

Ben: If browser tabs or the tray the was parent browser context, then we
would have semantic about what is active or not active.  But without that,
we don't have a way to talk about hidden/inactive or

... Would like it to be more coherent or consistent with HTML

Michal: I'm not sure if I agree that this is a browser-level context vs. a
OS-level context.

... In Chrome/Android you have the tab switcher which is in the browser.
We own that.  We're not in the risk of the OS closing that tab for us.
It's the OS level feature that can kill us.

... In Windows, in alt-tab, you can use the X to close a window, but that's
not as common.

... In mobile, the top-level overview is very common, as soon as the app
enters the switchers, we need to save state there.

Yoav: We have two switchers here, in the browser and in the OS.

Michal: And the OS one is the one we have to be concerned about

Yoav: Not sure browsers today extend the lifetime of a document in order
for it to save state, but I can imagine that could be possible in the
absence of sync XHR.

... We need OS-level signals to the browser that the OS is now in app
switching mode.

... Ryosuke, is that something we can figure out if the OS provides that.

Ryosuke: Hard to say

Philip: Specific case: In iOS, if you're in Safari and you swipe up, the
app selector shows.  If you swipe the app up, it will close.  My guess is
that the browser doesn't get time to run any handlers/etc before it closes.

... That's where visibility hidden would have to change if we added a 3rd
visibility mode of "preview" or whatever.

Yoav: A new thing would help you fire a "save state" event earlier.

... We'd need to make sure there's nothing in the handler that runs long
(e.g. sync XHR)

Ryosuke: Is this an issue in Android?

Philip: In my testing, Chrome does not fire this even if you close the
browser from the app switcher, while Firefox mobile did.  If those two and
Safari could, it would help that problem.

Yoav: There are a couple questions here:

... Can the browser fire that dismissal event at that point in time?

... Does sendBeacon() actually work in that case?

Philip: My test used localStorage to check, but I can also extend it to do
a sendBeacon and see if that arrives.

Alex: If we give developers the ability to do things in this save state
event, people will do things, and more and more things.  At some point
we'll need to draw a line and that will be a hard line to find.

Philip: Flip side of that is today developers know the current
notifications are unreliable, so they do more work proactively.  If we
could make the visibility event more reliable, it would give developers the
ability to always send data at the end instead of sending data pro-actively
during the page load process.

Yoav: Maybe there is a way for us to draw that line ahead of time -- draw
bounds on the reliability.  e.g. you have X milliseconds.

Michal: Mobile app platforms have some guidelines for reliability that we

... Two proposals are to fix hidden and ensure it's more reliable here

... Or, if we can find a different signal it may be hard to predict

... And if we're going to make hidden more reliable, is that the right
event, or should we make beforeunload the signal to use

Yoav: Problem with beforeunload and unload is that many people have already
crossed that line on the work they do in there.

Nicolas: I don't think beforeunload is the right event, because it's not
really unloading.

Philip: With beforeunload you could have 100 tabs that would all have to
run the event, where with visibility change we know it's always just a
single tab.

Yoav: Unload and beforeunload also have implications on BFCache on some

Benjamin: Isn't what you're talking about a "onexit" signal?

Michal: Yes, presumably

Philip: In page lifecycle discussion we had discussed a "backgrounded" state

Yoav: I would like to see if we could fix the bugs around this rather than
have another dismissal event we add.

Ian: I believe Sync XHR in Chrome is disabled in beforeunload, unload and
visibility events unless you opt-in to a Origin Trial that will go away in
Chrome 88.

Benjamin: Is that just Android?

Ian: The Intent to Experiment does not say it is just Android, but I can't
tell from here.

Yoav: Not just Android, all platforms

Ryosuke: I believe Safari already disables Sync XHR in beforeunload/unload,
but not sure about in visibility state changes.  But it also matters for
the network, how long does it take to be sent.

Yoav: AI: To determine on mobile OS's to see if it's possible to get
signals from the OS to be delivered to the browser when it goes into
preview mode.

... For example if the browser has 5 seconds to save state before it's
closed, we can make some decisions on what to report.

   - Send out a few Calls for Consensus for Incubations for the WG

- Nic

On Tue, Aug 11, 2020 at 7:09 PM Nic Jansma <> wrote:

> Hi everyone!
> On the agenda
> <>
> for our next call (August 13 @ 10am PT / 1pm ET) we aim to have discussions
> on:
>    - Page Visibility
>    - Preload
>    - Event Timing
>    - Third-Party Origin Trials
> If you have any additional items you'd like to discuss, please add to the
> agenda
> <>
> .
> Join us <>!
> The meeting will be recorded and published online afterwards.
> See you soon!
> - Nic Jansma
> @nicj

Received on Wednesday, 19 August 2020 14:13:57 UTC