 Add-to-homescreen behavior on Android is changing to give you more control. The Page Lifecycle API tells you when your tab has been suspended or restored. And the Payment Handler API makes it possible for web-based payment apps to support the payment request experience. I'm Pete LaPage. Let's dive in and see what's new for developers in Chrome 68. If your site meets the add-to-homescreen criteria, Chrome will no longer show the add-to-homescreen banner. Instead, you're in control over when and how to prompt the user. To prompt the user, listen for the Before Install Prompt event, then save the event and add a button or other UI element to your app to indicate that it can be installed. When the user clicks the Install button, call Prompt on the Saved Before Install Prompt event and then Chrome will show the Add-to-Homescreen dialog. To give you time to update your site, Chrome will show a mini-info bar the first time the user visits a site that meets the Add-to-Homescreen criteria. Once dismissed, the mini-info bar will not be shown again for a while. I've got a post with full details, including code samples that you can use, linked in the description below. When a user has a large number of tabs running, critical resources such as memory, CPU, battery, and the network can all be oversubscribed, leading to a bad user experience. If your site is running in the background, the system may suspend it to conserve resources. With the new Page Lifecycle API, you can now listen for and respond to these events. For example, if a tab needs to be discarded to conserve memory, the browser will fire a frozen event where you can store any necessary state. Then, when the user refocuses the tab, the resume event is fired, making it possible to restore any previous state. The spec and an explainer doc are on GitHub, linked in the description. The Payment Request API is an open, standard-based way to accept payments. The Payment Handler API extends the reach of payment requests by enabling web-based payment apps to facilitate payments directly within the payment request experience. As a seller, adding an existing web-based payment app is as easy as adding an entry to the supported methods property. If a service worker that can handle the specified payment method is installed, it will show up in the Payment Request UI, and the user can pay with it. EG has a great post that shows how to implement this for merchant sites and for payment handlers. So, check the description for details. These are just a few of the changes in Chrome 68 for developers. Of course, there's plenty more. Content embedded in an iframe requires a user gesture to navigate the top-level browsing context to a different origin. Since Chrome 1, the CSS cursor values for grab-and-grabbing have been prefixed. We now support the standard, unrefixed values, finally. And this is a big one. The HTTP cache is now ignored when requesting updates to a service worker, bringing Chrome in line with the spec and other browsers. All the details including links to docs and specs and more are in the description. And be sure to check out the latest new and Chrome DevTools videos to learn what's new in DevTools. Then, click the subscribe button and you'll get an email notification whenever we launch a new video. I'm Pete LaPage, and as soon as Chrome 69 is released, I'll be right here to tell you what's new in Chrome.