Chromium Blog

Chrome 47 Beta: Idle time work, splash screens, and desktop notification management

Thursday, October 22, 2015

The newest Chrome Beta channel release includes support for cooperative multitasking, splash screens for sites added to home screen, flexible desktop notifications, security fixes, and more. Unless otherwise noted, changes described below apply to Chrome for Android, Chrome OS, Linux, Mac, and Windows. Splash screens on Android Mobile devices are typically less powerful than desktops, meaning apps can take a few seconds to load. Splash screens allow apps to show something meaningful to users as the app loads, improving perceived performance. The new version of Chrome for Android brings splash screens to web apps when a site is launched from the Android home screen. The splash screen is shown immediately, even while Chrome itself is loading. Developers can customize the splash screen by setting a name, icon, background color, and notification bar color in the web app manifest. The splash screen disappears once the web app begins to draw to the screen, providing a more polished loading experience.

Cooperative multitasking with requestIdleCallback() To achieve a screen refresh rate of 60 frames per second, developers must guess when performance-critical tasks like rendering will finish and use timers to schedule around them. Unfortunately, developers can’t guarantee that low priority work won’t hurt performance because events like scrolling cannot be predicted. Now developers can explicitly set work to run during idle time using requestIdleCallback(). Functions registered with requestIdleCallback() are given a deadline and can return before that limit is reached to avoid jank. The function can register for another requestIdleCallback() to continue work during the next idle period. Auto dismissing notifications Push notifications have been enabled by service workers since Chrome 42. Sites such as social media or email can generate a large number of push notifications that take up screen space and aren’t particularly relevant unless viewed soon after posting. The new version of Chrome now allows developers to configure automatic dismissal of desktop notifications, improving the experience for these kinds of notifications. Sites can set NotificationOptions.requireInteraction to indicate the notification should remain onscreen until the user dismisses it. Other updates in this release

Array.prototype.includes() simplifies the syntax for checking array membership.

The rest parameters syntax allows functions with an indefinite number of arguments to be called using arrays.

Cache.matchAll() simplifies bulk searching of the cache and removes the need for polyfills.

RequestInit.referrer allows requests captured by service workers to match the original referrer.

The new Navigator.MediaDevices interface allows developers to enumerate connected media devices such as audio output.

Updated values for request properties in navigation FetchEvents offer improved spec compliance.

MouseEvent.getModifierState() makes input processing more powerful and consistent across MouseEvent and KeyboardEvent.

Developers can now more accurately detect input device capabilities using UIEvent.sourceCapabilities and InputDeviceCapabilities.firesTouchEvents.

Several SVG methods have been removed, including pixel conversions and hasExtension() methods on several elements.

Prefixed encrypted media extensions are now disabled in favor of unprefixed EMEs, which have more capabilities and conform to the spec.

Chrome no longer highlights the gaps between content when painting selections.

The notification center has been removed from Windows, Mac, and Linux to keep Chrome simpler.

Posted by Ross McIlroy, Scheduling Samurai

Streamlining Notifications on Desktop

Wednesday, October 14, 2015

This past spring, Chrome began supporting push notifications for web pages via the emerging web push standard. However, notifications in Chrome aren’t new; Chrome apps and extensions have supported push notifications on desktop since 2010. In some cases, these desktop notifications would appear while users were gone, so in 2013 Chrome launched the notification center, a place for users to find notifications from Chrome apps and extensions that they’d missed.

However, in practice, few users visit the notification center. To keep Chrome simple, it will be removed from Windows, Mac, and Linux in the upcoming release. The notification center on Chrome OS will remain unchanged.

The new notifications documentation reflects changes that will affect Chrome app and extension developers who send notifications to the center. Notifications sent solely to the notification center will now result in an error, and API events tied to the center will no longer fire. All other notifications will continue to work without requiring any changes.

With the growth of web push, notifications are an increasingly important way for users to engage with web pages they care about. By streamlining the experience on desktop, Chrome can ensure a simple notification experience on every platform.

Posted by Justin DeWitt, Software Engineer

Replying to reviews in the Chrome Web Store

Thursday, October 1, 2015

When we launched the Chrome Web Store Support Tab in 2012, our goal was to provide a communication channel that would enable you to have an open discussion with the users of your apps and extensions. Developers like you have reported that the tool has helped identify bugs faster, obtain ideas for new features, and prioritize work based on user impact. But we’ve also seen that many users continue to leave their feedback in the form of comments under the Reviews tab. Until now, the Web Store has not provided an option to respond to these comments, which has had the effect of leaving many users’ bug reports and feature suggestions unanswered, even after the issues have been addressed.
Today, we’re providing both you and your users the ability to reply to comments in the Reviews tab, in order to ensure that you can openly and clearly communicate about all relevant feedback.
To strengthen relationships with your users and ensure that the Reviews tab provides accurate information about your product, we recommend that you begin closely monitoring user reviews for bug reports and feature suggestions. Be sure to reply constructively to both negative and positive reviews, notify users when you have addressed their feedback, and thank the users who are your biggest advocates.
Before replying to user reviews, please read the commenting guidelines to ensure that your use of this feature is compliant with Chrome Web Store policies. Also remember that when posting reviews, your name and Google account will be shown publicly so that prospective users can see that you consistently provide high quality customer support. Head over to your reviews tab and start connecting with users today!
Posted by James Wagner, Product Lead and Reviews Wrangler

Chrome 46 Beta: Flexible animations and improved loading performance

Wednesday, September 2, 2015

The newest Chrome Beta channel release includes new CSS animation features, improved performance controls, and a large number of API tweaks. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS. Animating objects along author specified paths Previously, animating objects along an author-specified path required complex javascript code that could block important events like rendering and input. Developers can now animate any graphical object along an arbitrary path declaratively as a CSS property, allowing simpler code that doesn’t block rendering or input.
Complex animations using CSS Optimized image loading and service worker instrumentation Tools like srcset allow developers to serve an optimized image variant in a responsive way, but it can be cumbersome and inefficient to use in practice. Developers can now negotiate with the server to download the best image variant for a device using straightforward HTTP request headers. These headers communicate DPR, Viewport-Width, and the intended display width of the resource being fetched to the server.
In addition to improving image loading, developers can now instrument service workers to gather detailed fetch and script timing. Developers can also measure the startup time of service workers more accurately. Other updates in this release

As part of Chrome’s ongoing efforts to ship features from the ES2015 specification, Chrome now supports the spread operator and new.target.

To prevent user annoyance and conserve power, Chrome will now defer playback of autoplay videos in background tabs until the first time the tab is foregrounded.

Developers can now disable Chrome’s default scroll restoration behavior on history navigation when it interferes with the app’s user experience.

Sites can specify origins that Chrome should preconnect to in order to improve performance.

Sites launched from the home screen can now modify the default color of Chrome’s UI by specifying a theme color in their web manifest instead of a meta tag.

Sites that have been added to the homescreen can now set a background color to show while resources load.

Developers can now specify a URI for Chrome to report HTTP Public Key Pinning violations to, making man-in-the-middle attacks easier to find.

Events generated by user action can be differentiated from events generated by script using Event.isTrusted(), allowing developers to protect against fake clicks.

Developers can now use CSS.escape(), eliminating the need for complicated string escape code while handling user generated identifiers.

Modal dialogs are now blocked by default in sandboxed iframes, preventing embedded content from abusing APIs like alert.

Sites can now set an iframe attribute that allows sandboxed content to launch unrestricted windows.

As part of our continuing policy to remove powerful APIs on insecure origins, the Cache API is now restricted to HTTPS.

Cache.addAll() is now supported, removing the need for polyfills enabling bulk interactions with the cache.

The Fetch API now supports Request.redirect, allowing more control over redirects.

DOMExceptions can now be constructed from scripts, making polyfills easier to build for specs that require exceptions.

Timer-based polling is no longer necessary to use WebRTC DataChannels, making them more efficient and convenient.

DevTools now has better tool tips and custom network profiles.

Resource Timing extensions to the Performance interface are now available without prefixes.

The CSS intrinsic sizing values, which allow boxes to fit their contents, are no longer prefixed.

Request.context has been removed until the the spec has stabilized.

Posted by Eric Willigers, Software Engineer and Animations Acrobat

Chrome custom tabs smooth the transition between apps and the web

Wednesday, September 2, 2015

Android app developers face a difficult tradeoff when it comes to showing web content in their Android app. Opening links in the browser is familiar for users and easy to implement, but results in a heavy-weight transition between the app and the web. You can get more granular control by building a custom browsing experience on top of Android’s WebView, but at the cost of more technical complexity and an unfamiliar browsing experience for users. A new feature in the most recent version of Chrome called custom tabs addresses this tradeoff by allowing an app to customize how Chrome looks and feels, making the transition from app to web content fast and seamless.

Chrome custom tabs allow an app to provide a fast, integrated, and familiar web experience for users. Custom tabs are optimized to load faster than WebViews and traditional methods of launching Chrome. Apps can pre-load pages in the background so they appear to load nearly instantly when the user navigates to them. Apps can also customize the look and feel of Chrome to match their app by changing the toolbar color, adjusting the transition animations, and even adding custom actions to the toolbar so users can perform app-specific actions directly from the custom tab.
Custom tabs benefit from Chrome’s advanced security features, including its multi-process architecture and robust permissions model. They use the same cookie jar as Chrome, allowing a familiar browsing experience while keeping users’ information safe. For example, if a user has signed in to a website in Chrome, they will also be signed in if they visit the same site in a custom tab. Other features that help users browse the web, like saved passwords, autofill, Tap to Search, and Sync, are also available in custom tabs.

Custom tabs are easy for developers to integrate into their app by tweaking a few parameters of their existing VIEW intents. Basic integrations require only a few extra lines of code, and a support library makes more complex integrations easy to accomplish, too. Since custom tabs is a feature of Chrome, it’s available on any version of Android where recent versions of Chrome are available.
Users will begin to experience custom tabs in the coming weeks in Feedly, The Guardian, Medium, Player.fm, Skyscanner, Stack Overflow, Tumblr, and Twitter, with more coming soon. To get started integrating custom tabs into your own application, check out the developer guide.
Posted by Yusuf Ozuysal, Chief Tab Customizer

Scheduling timers to improve input responsiveness

Wednesday, August 26, 2015

A good frame rate is important to maintain a fast browsing experience. A few months ago, Chrome added a scheduler, a new under-the-hood feature that places tasks in the idle time between rendering frames to help hit 60 frames per second. Chrome’s frame rate can be reduced by Javascript timers executing at the wrong time, making them a natural next candidate to optimize with the scheduler. The most recent version of Chrome beta reschedules Javascript timers to create a smoother experience when the user is interacting with a page.

Javascript timers enable web developers to write code that checks in on a page periodically with APIs like setTimeout. Advanced developers can use setTimeout to schedule their code at opportune times, but they often don't have enough information to schedule it optimally. A timer’s function is placed into the main execution queue, meaning that if the function is run at the wrong time, it could block time-critical work that shares the queue, like input or rendering. Chrome has signals that important work is incoming, but before M45 they were ignored for timers.

When the user taps the page, they often interact with it again immediately or Chrome needs to re-render part of the screen. The scheduler now delays impending expensive timers after a tap in anticipation of these tasks, allowing many web pages to be scheduled more efficiently. In practice, this can result in up to a 50% input latency improvement on websites that use timers heavily.

The latest version of Chrome scrolling a timer heavy site with no optimizations (left) and delayed timer execution (right).
Scheduling timers intelligently is just one use of the scheduler’s infrastructure. To keep improving, Chrome will continue integrating the scheduler with more rendering engine tasks. Using cycles wisely is one way to keep the web fast for everyone.
Posted by Alex Clarke, Software Engineer and Timer Tamer

Protecting users from deceptive inline installation

Thursday, August 6, 2015

Unwanted and deceptively installed extensions are a leading cause of user complaints, and over the last few years we’ve taken several steps to address the problem. Today we’re taking another step in our ongoing effort to protect Chrome users: disabling inline installation for extensions linked to deceptive sites and ads.
Inline installation was introduced in 2011 as a way for users to seamlessly install extensions from developers’ websites. Unfortunately, this mechanism has been abused by deceptive sites and ads that trick users into installing unwanted extensions.

This ad appears to be a software update but actually links to an inline installation site for a Chrome extension.
To help address this problem, on September 3 we’ll begin disabling inline installation for extensions that employ these deceptive tactics. For these extensions, inline installation attempts will be redirected to the extension’s product details page in the Chrome Web Store, allowing the user to make an informed decision about whether to install.
Although less than 0.2% of all extensions will be affected by this change, it’s an important step to maintain a healthy extension ecosystem for users and the vast majority of extension developers who don’t use deceptive tactics. If you have any questions regarding this change, please reach out to us at chromewebstore-policy@google.com. Posted by Andrew Kim and Ben Ackerman, Chrome Policy and Anti-Abuse Team