Nic Jansma, Yoav Weiss, Ian Clelland, Noam Helfman, Ryosuke Niwa, Alex Christensen, Jason Chase, Thomas Kelly, Nicolás Peña, Philip Walton, Chris Harrleson, Sean Feng, Benjamin De Kosnik, Michal Mocny
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 origin.
… 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 shipping
Benjamin: Confirmed
Ryosuke: No trials for Safari
Jason: Feel free to reach out with questions
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.
... Nicolás 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 server/etc.
... 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 "invisible"
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 callback
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 tab.
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 visible/active/inactive.
... 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 could
... 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.
Nicolás: 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 browsers.
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.