Planet Chromium

June 20, 2019

Chromium Blog

WebAssembly brings Google Earth to more browsers

About 14 years ago, Google Earth gave users a rush of excitement by allowing them to  zoom right in on their childhood homes. But that could happen only once they downloaded and installed the application. Earth was released as a native application because rendering the whole world in real time required advanced technologies that weren’t available in the browser. 


As the Web progressed, we wanted Earth to be available on the platform so it could reach as many people as possible and let them experience the entire world at their fingertips. Web apps offer a better user experience because they’re linkable, meaning you can share access to the whole experience with a single click; they’re secure, since users aren’t at risk of viruses that can come with software downloads; and they’re composable, meaning we can embed them in other parts of the web.


In WebAssembly (Wasm), the W3C web standard for bringing native code to the web, the Earth team found a solution to allow Google Earth to move across multiple browsers—something we’ve been working on for a while now. Earth first came to the Web about two years ago using Native Client (NaCl), a Chrome-only solution—at the time. It was the only way to run native code in the browser and offer the performance users expect in modern web applications. But cross-browser compatibility is not as easy as we would like, since not every browser supports new technologies the same way. 


Using WebAssembly, we see more possibilities not just for making apps more accessible across browsers, but smoothing out the online experience, as we’ve seen with Google Earth. You can check out the Earth preview beta to see what the Earth team has achieved and read about their technical implementation here.


How WebAssembly works with threaded applications
If you plan to work in WebAssembly, it’s important to understand some of the specifics, particularly around threading.


Some browsers offer multi-threading support and others don't. In the case of Google Earth, it is constantly streaming data to the browser, decompressing it and making it ready for rendering to the screen. Being able to do this work on a background thread has shown a clear improvement in the performance of Earth in the browser.


The Chromium-based browsers—including Chrome, the forthcoming version of Edge, and Opera—all offer support for WebAssembly (some with multi-threading, others without). Once the new version of Edge based on Chromium ships, apps in WebAssembly will work as well in Edge as they do in Chrome. Firefox offers good support for WebAssembly, but had to disable support for multi-threading due to a SharedArrayBuffer issue. And while Opera is based on Chromium, the current version of Opera only offers single-threaded support of WebAssembly. Safari has a strong implementation of WebAssembly, but it lacks full support for WebGL2. Our deep-dive technical post offers more details about WebAssembly support across the browsers.


Emscripten: The tool that enabled Earth to port to the browser
Taking an application that was originally created for native operating systems and bringing it to the web is no small task. The Emscripten toolchain helps developers compile their C++ into WebAssembly, also also emulates many of the OS interfaces that native applications use. For example, an application may use the POSIX API fopen which tells the OS to open a file. Emscripten sees this call and offers the correct behavior through browser technologies such as local storage.  It does the same thing for turning OpenGL calls into WebGL calls. Along with many other features, it dramatically eases the work of bringing a native app to the web.


Emscripten has been used to port other applications to the web, such as the 35-year-old AutoCAD codebase and more recent applications like Sketchup.


What’s coming next for WebAssembly
There are several features coming to WebAssembly in the future that Earth will use to improve the web experience:


SIMD support: SIMD (single instruction, multiple data) lets a single CPU instruction act on multiple pieces of data. When it’s set up in the right way, SIMD allows for high throughput of data processing. When the first set of SIMD support arrives later this year for WebAssembly, we hope it will dramatically improve Earth’s performance. 


Dynamic linking: This feature will give Earth the chance to optimize load time, and opens the door to embedding Earth in other web pages and online experiences. Currently, all modules that interact have to be compiled at the same time. With dynamic linking, you can break up an application into many modules and ship a very small client, then load all the other parts over time (known as lazy loading).


Better debugging: Today, Wasm supports source maps so that developers can see their source code in the developer tools. That’s a great first step, but we want to also allow developers to inspect variables and see proper stack traces.

Earth has now taken a major step by adopting a cross-browser standard that lets them bring the application to more browsers—with more improvements coming in the future. Consider trying out WebAssembly for yourself and your native code to reach all your users with a consistent, performant experience.



Posted by Thomas Nattestad, Product Manager for Web Assembly, V8 and Web Capabilities

by Chromium Blog (noreply@blogger.com) at June 20, 2019 09:59 AM

June 19, 2019

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 76.0.3809.36 for Windows, Mac, and, Linux.


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at June 19, 2019 06:17 PM

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 76 (76.0.3809.36) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 19, 2019 05:52 PM

Chrome for Android Update

Hi, everyone! We've just released Chrome 75 (75.0.3770.101) for Android: it'll become available on Google Play over the next few weeks.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at June 19, 2019 03:50 PM

Chrome for Android Update

Hi, everyone! We've just released Chrome 75 (75.0.3770.89) for Android: it'll become available on Google Play over the next few weeks.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at June 19, 2019 02:50 PM

Google Chrome

The Chromebook App Hub offers more choices in the classroom

Educators can now find apps and ideas for how to use them for their Chromebook using classrooms on the new Chromebook App Hub.

June 19, 2019 01:30 PM

June 18, 2019

Igalia Chromium

Manuel Rego: Speaking at CSS Day 2019

This year I got invited to speak at CSS Day, this is an amazing event that every year brings to Amsterdam great speakers from all around the globe to talk about cutting edge topics related to CSS.

Pictures of speakers and MC at CSS Day 2019 Speakers and MC at CSS Day 2019

The conference happened in the beautiful Compagnietheater. Kudos to the organization as they were really kind and supportive during the whole event. Thanks for giving me the opportunity to speak there.

Compagnietheater in Amsterdam Compagnietheater in Amsterdam

For this event I prepared a totally new talk, focused on explaining what it takes to implement something like CSS Grid Layout in a browser engine. I took an idea from Jen Simmons and implemented a new property grid-skip-areas during the presentation, this was useful to explain the different things that happen during the whole process. Video of the talk is available on YouTube, and the slides are available if you are interested too; however, note that some of them won’t work on your browser unless you built the linked patches.

The feedback after the talk was really good, everyone seemed to like it (despite the fact that I showed lots of slides with C++ code) and find it useful to understand what’s going on behind the scenes. Thank you very much for your kind words! 😊


Somehow with this talk I was explaining the kind of things we do at Igalia and how we can help to fill the gaps left by browser vendors in the evolution of the Web Platform. Igalia has now a solid position inside the Web community, which makes us an excellent partner in order to improve the platform aligned with your specific needs. If you want to know more don’t hesitate to read our website or contact us directly.

I hope you enjoy it! 😀

June 18, 2019 10:00 PM

Chromium Blog

New Chrome Protections from Deception

Chrome was built with security in mind from the very beginning. Today we’re launching two new features to help protect users from deceptive websites. The Suspicious Site Reporter Extension will improve security for Chrome users by giving power users an easy way to report suspicious sites to Google Safe Browsing. We’re also launching a new warning to protect users from sites with deceptive URLs.



We designed Chrome to be secure by default, and easy to use by everyone. Google Safe Browsing has helped protect Chrome users from phishing attacks for over 10 years, and now helps protect more than 4 billion devices every day across multiple browsers and apps by showing warnings to people before they visit dangerous sites or download dangerous files. We’re constantly improving Safe Browsing, and now you can help.



Safe Browsing works by automatically analyzing the websites that we know about through Google Search’s web crawlers, and creating lists of sites that are dangerous or deceptive. With the Suspicious Site Reporter extension, you can help Safe Browsing protect web users by reporting suspicious sites. You can install the extension to start seeing an icon when you’re on a potentially suspicious site, and more information about why the site might be suspicious. By clicking the icon, you’re now able to report unsafe sites to Safe Browsing for further evaluation. If the site is added to Safe Browsing’s lists, you’ll not only protect Chrome users, but users of other browsers and across the entire web.


Help us protect web users by reporting dangerous or deceptive sites to Google Safe Browsing through the Suspicious Site Reporter extension.

One way that deceptive sites might try to trick you is by using a confusing URL. For example, it’s easy to confuse “go0gle.com” with “google.com”. In Chrome 75, we’re launching a new warning to direct users away from sites that have confusing URLs.


Starting in the current version of Chrome (75), you’ll see a warning when the page URL might be confused for URLs of sites you’ve visited recently.


This new warning works by comparing the URL of the page you’re currently on to URLs of pages you’ve recently visited. If the URL looks similar, and might cause you to be confused or deceived, we’ll show a warning that helps you get back to safety.



We believe that you shouldn't have to be a security expert to feel safe on the web, and that many Chrome power-users share our mission to make the web more secure for everyone. We’ll continue improving Chrome Security to help make Chrome easy to use safely, and are looking forward to collaborating with the community to further that goal. Install the new extension and start helping protect web users!



Posted by Emily Schechter, Chrome Product Manager

by Chromium Blog (noreply@blogger.com) at June 18, 2019 11:01 AM

Google Chrome Releases

Stable Channel Update for Desktop

The stable channel has been updated to 75.0.3770.100 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.


A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at June 18, 2019 09:58 AM

June 14, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 77.0.3824.6 for Windows, Mac, and Linux.



A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Lakshmana Pamarthy
Google Chrome

by Lakshmana Pamarthy (noreply@blogger.com) at June 14, 2019 05:30 PM

June 13, 2019

Google Chrome Releases

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 76 (76.0.3809.21) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 13, 2019 09:33 PM

Stable Channel Update for Desktop

The stable channel has been updated to 75.0.3770.90 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.

Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 1 security fix, contributed by an external researcher. Please see the Chrome Security Page for more information.

[$N/A][961413] High CVE-2019-5842: Use-after-free in Blink. Reported by BUGFENSE Anonymous Bug Bounties https://bugfense.io on 2019-05-09

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.




A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at June 13, 2019 02:22 PM

Chromium Blog

Chrome 76 Beta: dark mode, payments, new PWA features and more

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Find more information about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 76 is beta as of June 13, 2019.

Dark mode

Many operating systems now support inverted color schemes with a system setting referred to as ‘dark theme' or ‘dark mode', depending on the system.


The prefers-color-scheme media query allows a website or web app to adopt the preferred display mode of the user. Use the query in your CSS code like so:


@media (prefers-color-scheme: dark) {
body {
color: white;
background-color: black;
}
}


What is left out of this is the explanation? For that, watch our web platform blog for an article titled "Hello Darkness, My Old Friend".

Payments API

Over the last few versions of Chrome we've rolled out a number of improvements to the payments APIs. These APIs provide a way to interact with proprietary payment systems without needing to build your own user interactions. Changes in Chrome 75 included replacing hasEnrolledInstrument() with canMakePayment() and removal of languageCode from the billing address. With the detailsPromise option Chrome 75 gives PaymentRequest.show() a means of performing a quick server call before showing payment details to the buyer.

Chrome 76 brings three changes to the payment realm. Now implemented are features that allow a merchant website or web app to respond when a user changes payment instruments. Additionally, the PaymentRequestEvent has a new method called changePaymentMethod() and the PaymentRequest object now supports an event handler called paymentmethodchange. You can use both to notify a merchant when the user changes payment instruments. The former returns a promise that resolves with a new PaymentRequest instance.

Additionally, Chrome now makes it easier to use the payments APIs for self-signed certificates on the local development environment. To do this, launch Chrome from a command line with the —ignore-certificate-errors flag.

For detailed information about these features, read Web Payments Updates.

Improvements for Progressive Web Apps

Install Progressive Web Apps on the desktop with ease

On desktop, there is typically no indication to a user that a Progressive Web App is installable, and if it is, the install flow is hidden within the three dot menu.

In Chrome 76, we're making it easier for users to install Progressive Web Apps on the desktop by adding an install button to the omnibox.


If a site meets the Progressive Web App installability criteria, Chrome shows an install icon in the omnibox. There is no extra work required from developers. Clicking the button prompts the user to install the PWA.

Control the Add to Home Screen mini-infobar

In Chrome 76, we're giving you control over the add to home screen mini-infobar.




Chrome shows the mini-infobar the first time a user visits a site that meets the Progressive Web App installability criteria. Developers want to prevent the mini-infobar from appearing, and provide their own install promotion instead.

To do this, listen for the beforeinstallprompt event, and call preventDefault()
on it. Then, update your UI to notify the user by adding an install button or other element. Depending on your app, there are several different patterns you can use to promote installation of your PWA.

The add to home screen mini-infobar is still a temporary measure. We are experimenting with new UI patterns for giving Progressive Web App users the ability to install, and do this in a way that reduces clutter in the browsing experience.

Updating WebAPKs more frequently

When a PWA is installed on Android, Chrome automatically requests and installs a WebAPK. Chrome periodically checks to see if the manifest has changed, and if a new WebAPK is required. Starting in Chrome 76, Chrome will check the manifest more frequently: checking every day, instead of every three days. If any of the key properties have changed, Chrome will request and install a new WebAPK.

Other features in this release

Animation.updatePlaybackRate

Adds Animation.updatePlaybackRate(), which lets you seamlessly transition the playback rate of an animation such that there is no visible jump in the animation. Current time is preserved at the instance the new playback rate takes effect.

Async clipboard: read and write images

Implements programmatic copying and pasting of images for the Async Clipboard API. This change also updates navigator.clipboard.read() and navigator.clipboard.write() to comply with the specification. Programmatic copying and pasting of images is Chromium's top starred bug.

Escape key is not a user activation

The escape key is no longer treated as a user activation. Browsers prevent calls to abusable APIs (like popup, fullscreen, vibrate, etc.) unless the user activates the page through direct interactions. Not all interactions trigger user activation. For example, clicking on a link or typing in a textbox does, but swiping fingers on a screen or hovering with the mouse cursor does not. Since users never intend to interact with the page through the escape key, it should not trigger user activation.

Fetch Metadata

Introduces a new HTTP request header that sends additional metadata about a request's provenance (is it cross-site, is it triggered from <img>, etc.) to the server to allow it to make security decisions which might mitigate some kinds of attacks based on timing the server's response (XSS leaks and others).

For example, it is unlikely that a bank's "Transfer all money" endpoint would be referenced from an <img> tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than deliver them to the application backend.

form.requestSubmit()

Adds the form.requestSubmit() function, which requests form submission. It includes interactive constraint validation, dispatches a submit event, and takes a reference to the submitter button.

ImageCapture support for focusDistance constraint

The Image Capture API provides a means to set the focusMode to manual which is not useful if you cannot set the focus distance. This change provides an interface for getting focus range values and setting focus distance value.

Implement Animation.pending

Adds the pending attribute to the Web Animations API. A pending animation is one that is waiting on an asynchronous operation that affects the play state. Adding support for this attribute does not affect the rendering or timing of animations, but simply exposes the signal.

IndexedDB transaction explicit commit API call

Adds a commit() function to IDBTransaction objects, which explicitly marks a transaction as not accepting further requests. Currently, IndexedDB only commits a transaction after all associated requests have had their completion event handlers executed, and no new requests have been queued by the event handlers. Developers can use the explicit commit() function to shave a few event loop cycles off of the latency of their transactions.

The primary benefit of explicit commit is that it increases the throughput of read and write requests made on an object store. This is a clear performance benefit in terms of the rate at which operations can be processed. Additionally, the increase in speed is advantageous because it adds stability to IndexedDB by reducing the probability that a disruptive event occurs within the lifetime of a transaction.

JavaScript

DateTimeFormat dateStyle and timeStyle
Adds dateStyle and timeStyle options to functions on Intl.DateTimeFormat, specifically formatToParts() and resolveOptions(). These options provide a compact way to request the appropriate, locale-specific date and time of given length styles.

Locale sensitive BigInt.prototype.toLocaleString and allow Intl.NumberFormat format/formatToParts to take BigInt.
Changes BigInt.prototype.toLocaleString() to locale-sensitive number formatting and changes Intl.NumberFormat.prototype.format() and formatToParts() to accept BigInt as input.

Media capabilities in workers

Enables the Media Capabilities API in all types of workers to help website and web apps pick the best media to stream from a worker. The information can then be used to create the MediaStream from a worker.

Promise.allSettled

Adds Promise.allSettled(), which returns a promise that is fulfilled with an array of promise state snapshots, but only after all the original promises have settled, in other words after it has either resolved or rejected.

Simpler reading methods for Blob interface

Adds three new methods to the Blob interface to perform read operations: text(), arrayBuffer(), and stream().

WebRTC

RTCSctpTransport
Exposes information about the SCTP transport that is used to carry WebRTC data channels such as max-message-size and max channels.

RTCRtpSender.setStreams
Allows changing the association between the track associated with an RTCRtpSender and streams. Stream association causes tracks in the same stream to be synchronized. This is useful, for example, if during a call a user switches from a front-facing camera to a back-facing camera and the application uses RTCRtpSender.replaceTrack(). On the receiving end the new track must be associated with the existing stream and synchronized with its auto track.

RTCRtpTransceiver.setCodecPreferences()
Adds the setCodecPreferences() method, which overrides the default codec preferences used by the user agent. This allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.

white-space: break-spaces

The white-space:break-spaces value allows authors to specify that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module specification's Trimming and Positioning rules) must be broken.

Removals

Remove feature policy: lazyload

The lazyload feature policy was intended to allow developers to selectively control the lazyload attribute on the <iframe> and <img> tags to provide more control over loading delay for embedded contents and images on a per origin basis.

The policy is removed in favor of a newer feature policy for loading, namely loading-frame-default-eager which is more aligned with how the loading attribute will be used. The removal applies to both the Feature-Policy header and the <iframe> allow attribute.

Remove outputs from MediaStreamAudioDestinationNode

According to the specification, the MediaStreamAudioDestinationNode in the Web Audio API should have no outputs. Chrome's implementation has a single output which has been removed.

Remove insecure usage of DeviceMotionEvent

Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium's implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

by Chromium Blog (noreply@blogger.com) at June 13, 2019 01:57 PM

Google Chrome Releases

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 76 to the beta channel for Windows, Mac and Linux. Chrome 76.0.3809.25 contains our usual under-the-hood performance and stability tweaks, but there are also some cool new features to explore - please head to the Chromium blog to learn more!


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at June 13, 2019 12:49 PM

June 12, 2019

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 75.0.3770.90 for Windows, Mac, and, Linux.

A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at June 12, 2019 05:49 PM

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 75 (75.0.3770.89) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at June 12, 2019 05:25 PM

Chromium Blog

Web Request and Declarative Net Request: Explaining the impact on Extensions in Manifest V3

The Story So Far
As part of an effort to increase user security and privacy, Chrome is planning a number of changes to the extensions platform. We announced some of these changes last October, and have provided additional context on them today. These changes to the platform are being implemented as part of Manifest V3 – the next version of the Chrome Extensions platform.

One of these changes is to move away from the blocking version of the Web Request API towards a new API, called Declarative Net Request. There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers. This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers.

In order to improve the security and privacy guarantees of the extensions platform, we are rethinking some of the extension platform's core APIs. That's why we're planning to replace the blocking Web Request API with the Declarative Net Request API.



How Web Request Works

With Web Request, Chrome sends all the data in a network request to the listening extension - including any sensitive data contained in that request like personal photos or emails. The extension has a chance to evaluate the request, and then tells Chrome what to do with the request: allow it, block it, or send it with some modifications. As a result, extensions that leverage the Web Request API typically have access to read and manipulate everything a user does on the web.


While this API is used by good actors to implement powerful features like content blockers, it can also be - and has been - abused. Because all of the request data is exposed to the extension, it makes it very easy for a malicious developer to abuse that access to a user’s credentials, accounts, or personal information. Since January 2018, 42% of malicious extensions use the Web Request API.

In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible.

As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses.



Enter Declarative Net Request

The Declarative Net Request API works differently than the Web Request API. Instead of Chrome sending all the information about a request to the listening extensions at the time of the request, extensions register rules that tell Chrome what to do if certain types of requests are seen.


This approach has advantages for both user security and privacy, as well as performance. With a declarative approach, Chrome does not need to expose any sensitive data to the extension. The browser can perform the action requested by the extension without sending it all the data associated with the network request, because the extension already specified the conditions under which different actions are taken. This enables the extension to perform content blocking without needing access to all of a user’s personal information.

This has significant performance implications. Most importantly, a persistent, long-running process is no longer necessary because rules are registered before requests are made rather than needing to process them at runtime. This also cuts down on the cost of serializing all the request data and shuttling the inter-process messages to the listening extensions. These performance improvements will make extensions significantly more viable on resource-constrained platforms.



Why Not Both?
In addition to the performance concerns raised above, the Chrome team strongly believes that users should not have to expose their emails, photos, social media, or any other sensitive data to an extension if the extension doesn’t actually need that access to perform its function. And historically, when extension developers are given the choice between capability and security, the vast majority of developers choose capability. We've seen this repeatedly on the extensions platform with event pages, optional permissions, and activeTab.



Enterprise
Enterprises, schools, and businesses often require different network and software controls to comply with corporate policies. Additionally, these organizations typically have administrators whose role it is to understand and set up their environments.

Chrome provides enterprise controls through its administrator policies. The blocking version of the Web Request API remains available for managed extensions because of the deep integrations that enterprises may have between their software suites and Chrome. System administrators can continue to manage Chrome in enterprise environments for free using OS-provided mechanisms to deploy Chrome policies.



Moving Forward
Declarative Net Request, and the whole of Manifest V3, is still very much in design and development. We are continuing to iterate on it, responding to community feedback and working with developers to help support different use cases.

Since the original announcement of the Declarative Net Request API, we have added significant functionality to the API as a result of these discussions. The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.

We are actively exploring other ways to expand this API, including adding methods to get feedback about matched rules, and support for richer redirects leveraging URL manipulation and regular expressions. Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.

We will continue working with the developer community moving forward. We understand that adopting Manifest V3 will require developers to update their extensions and we will continue to support them through this transition.



Posted by Simeon Vincent, Developer Advocate for Chrome Extensions

by Chromium Blog (noreply@blogger.com) at June 12, 2019 11:00 AM

June 11, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 76.0.3809.21 for Windows, Mac, and Linux.



A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at June 11, 2019 10:39 AM

June 10, 2019

Igalia Chromium

Javier Fernández: A new terminal-style line breaking with CSS Text

The CSS Text 3 specification defines a module for text manipulation and covers, among a few other features, the line breaking behavior of the browser, including white space handling. I’ve been working lately on some new features and bug fixing for this specification and I’d like to introduce in this posts the last one we made available for the Web Platform users. This is yet another contribution that came out the collaboration between Igalia and Bloomberg, which has been held for several years now and has produced many important new features for the Web, like CSS Grid Layout.

The feature

I guess everybody knows the white-space CSS property, which allows web authors to control two main aspects of the rendering of a text line: collapsing and wrapping. A new value break-spaces has been added to the ones available for this property, which allows web authors to emulate a terminal-like line breaking behavior. This new value operates basically like pre-wrap, but with two key differences:

  • any sequence of preserved white space characters takes up space, even at the end of the line.
  • a preserved white space sequence can be wrapped at any character, moving the rest of the sequence, intact, to the line bellow.

What does this new behavior actually mean ? I’ll try to explain it with a few examples. Lets start with a simple but quite illustrative demo which tries to emulate a meteorology monitoring system which shows relevant changes over time, where the gaps between subsequent changes must be preserved:



 #terminal {
  font: 20px/1 monospace;
  width: 340px;
  height: 5ch;
  background: black;
  color: green;
  overflow: hidden;
  white-space: break-spaces;
  word-break: break-all;
 }


    

Another interesting use case for this feature could be a logging system which should preserve the text formatting of the logged information, considering different window sizes. The following demo tries to describe this such scenario:



body { width: 1300px; }
#logging {
  font: 20px/1 monospace;
  background: black;
  color: green;

  animation: resize 7s infinite alternate;

  white-space: break-spaces;
  word-break: break-all;
}
@keyframes resize {
  0% { width: 25%; }
  100% { width: 100%; }
}

Hash: 5a2a3d23f88174970ed8 Version: webpack 3.12.0 Time: 22209ms Asset Size Chunks Chunk Names pages/widgets/index.51838abe9967a9e0b5ff.js 1.17 kB 10 [emitted] pages/widgets/index img/icomoon.7f1da5a.svg 5.38 kB [emitted] fonts/icomoon.2d429d6.ttf 2.41 kB [emitted] img/fontawesome-webfont.912ec66.svg 444 kB [emitted] [big] fonts/fontawesome-webfont.b06871f.ttf 166 kB [emitted] img/mobile.8891a7c.png 39.6 kB [emitted] img/play_button.6b15900.png 14.8 kB [emitted] img/keyword-back.f95e10a.jpg 43.4 kB [emitted] . . .

Use cases

In the demo shown before there are several cases that I think it’s worth to analyze in detail.

A breaking opportunity exists after any white space character

The main purpose of this feature is to preserve the white space sequences length even when it has to be wrapped into multiple lines. The following example tries to describe this basic use case:



.container {
  font: 20px/1 monospace;
  width: 5ch;
  white-space: break-spaces;
  border: 1px solid;
}

XX XX

The example above shows how the white space sequence with a length of 15 characters is preserved and wrapped along 3 different lines.

Single leading white space

Before the addition of the break-spaces value this scenario was only possible at the beginning of the line. In any other case, the trailing white spaces were either collapsed or hang, hence the next line couldn’t start with a sequence of white spaces. Lets consider the following example:



.container {
  font: 20px/1 monospace;
  width: 3ch;
  white-space: break-spaces;
  border: 1px solid;
}

XX XX

Like when using pre-wrap, the single leading space is preserved. Since break-spaces allows breaking opportunities after any white space character, we break after the first leading white space (” |XX XX”). The second line can be broken after the first preserved white space, creating another leading white space in the next line (” |XX | XX”).

However, lets consider now a case without such first single leading white space.



.container {
  font: 20px/1 monospace;
  width: 3ch;
  white-space: break-spaces;
  border: 1px solid;
}

XXX XX

Again, it s not allowed to break before the first space, but in this case there isn’t any previous breaking opportunity, so the first space after the word XX should overflow (“XXX | XX”); the next white space character will be moved down to the next line as preserved leading space.

Breaking before the first white space

I mentioned before that the spec states clearly that the break-space feature allows breaking opportunities only after white space characters. However, it’d be possible to break the line just before the first white space character after a word if the feature is used in combination with other line breaking CSS properties, like word-break or overflow-wrap (and other properties too).



.container {
  font: 20px/1 monospace;
  width: 4ch;
  white-space: break-spaces;
  overflow-wrap: break-word;
  border: 1px solid;
}

XXXX X

The two white spaces between the words are preserved due to the break-spaces feature, but the first space after the XXXX word would overflow. Hence, the overflow-wrap: break-word feature is applied to prevent the line to overflow and introduce an additional breaking opportunity just before the first space after the word. This behavior causes that the trailing spaces are moved down as a leading white space sequence in the next line.

We would get the same rendering if word-break: break-all is used instead overflow-wrap (or even in combination), but this is actualy an incorrect behavior, which has the corresponding bug reports in WebKit (197277) and Blink (952254) according to the discussion in the CSS WG (see issue #3701).

Consider previous breaking opportunities

In the previous example I described a combination of line breaking features that would allow breaking before the first space after a word. However, this should be avoided if there are previous breaking opportunities. The following example is one of the possible scenarios where this may happen:



.container {
  font: 20px/1 monospace;
  width: 4ch;
  white-space: break-spaces;
  overflow-wrap: break-word;
  border: 1px solid;
}

XX X X

In this case, we could break after the second word (“XX X| X”), since overflow-wrap: break-word would allow us to do that in order to avoid the line to overflow due to the following white space. However, white-space: break-spaces only allows breaking opportunities after a space character, hence, we shouldn’t break before if there are valid previous opportunities, like in this case in the space after the first word (“XX |X X”).

This preference for previous breaking opportunities before breaking the word, honoring the overflow-wrap property, is also part of the behavior defined for the white-space: pre-wrap feature; although in that case, there is no need to deal with the issue of breaking before the first space after a word since trailing space will just hang. The following example uses just the pre-wrap to show how previous opportunities are selected to avoid overflow or breaking a word (unless explicitly requested by word-break property).



.container {
  font: 20px/1 monospace;
  width: 2ch;
  white-space: pre-wrap;
  border: 1px solid;
}

XX
overflow-wrap:
break-word
word-break:
break-all

In this case, break-all enables breaking opportunities that are not available otherwise (we can break a word at any letter), which can be used to prevent the line to overflow; hence, the overflow-wrap property doesn’t take any effect. The existence of previous opportunities is not considered now, since break-all mandates to produce the longer line as possible.

This new white-space: break-spaces feature implies a different behavior when used in combination with break-all. Even though the preference of previous opportunities should be ignored if we use the word-break: break-all, this may not be the case for the breaking before the first space after a word scenario. Lets consider the same example but using now the word-break: break-all feature:



.container {
  font: 20px/1 monospace;
  width: 4ch;
  white-space: break-spaces;
  overflow-wrap: break-word;
  word-break: break-all;
  border: 1px solid;
}

XX X X

The example above shows that using word-break: break-all doesn’t produce any effect. It’s debatable whether the use of break-all should force the selection of the breaking opportunity that produces the longest line, like it happened in the pre-wrap case described before. However, the spec states clearly that break-spaces should only allow breaking opportunities after white space characters. Hence, I considered that breaking before the first space should only happen if there is no other choice.

As a matter of fact, specifying break-all we shouldn’t considering only previous white spaces, to avoid breaking before the first white space after a word; the break-all feature creates additional breaking opportunities, indeed, since it allows to break the word at any character. Since break-all is intended to produce the longest line as possible, this new breaking opportunity should be chosen over any previous white space. See the following test case to get a clearer idea of this scenario:



.container {
  font: 20px/1 monospace;
  width: 4ch;
  white-space: break-spaces;
  overflow-wrap: break-word;
  word-break: break-all;
  border: 1px solid;
}

X XX X

Bear in mind that the expected rendering in the above example may not be obtained if your browser’s version is still affected by the bugs 197277(Safari/WebKit) and 952254(Chrome/Blink). In this case, the word is broken despite the opportunity in the previous white space, and also avoiding breaking after the ‘XX’ word, just before the white space.

There is an exception to the rule of avoiding breaking before the first white space after a word if there are previous opportunities, and it’s precisely the behavior the line-break: anywhere feature would provide. As I said, all these assumptions were not, in my opinion, clearly defined in the current spec, so that’s why I filed an issue for the CSS WG so that we can clarify when it’s allowed to break before the first space.

Current status and support

The intent-to-ship request for Chrome has been approved recently, so I’m confident the feature will be enabled by default in Chrome 76. However, it’s possible to try the feature in older versions by enabling the Experimental Web Platform Features flag. More details in the corresponding Chrome Status entry. I want to highlight that I also implemented the feature for LayoutNG, the new layout engine that Chrome will eventually ship; this achievement is very important to ensure the stability of the feature in future versions of Chrome.

In the case of Safari, the patch with the implementation of the feature landed in the WebKit’s trunk in r244036, but since Apple doesn’t announce publicly when a new release of Safari will happen or which features it’ll ship, it’s hard to guess when the break-spaces feature will be available for the web authors using such browser. Meanwhile, It’s possible to try the feature in the Safari Technology Preview 80.

Finally, while I haven’t see any signal of active development in Firefox, some of the Mozilla developers working on this area of the Gecko engine have shown public support for the feature.

The following table summarizes the support of the break-spaces feature in the 3 main browsers:

Chrome Safari Firefox
Experimental M73 STP 80 Public support
Ship M76 Unknown Unknown

Web Platform Tests

At Igalia we believe that the Web Platform Tests project is a key piece to ensure the compatibility and interoperability of any development on the Web Platform. That’s why a substantial part of my work to implement this relatively small feature was the definition of enough tests to cover the new functionality and basic use cases of the feature.

white-space overflow-wrap word-break
pre-wrap-008
pre-wrap-015
pre-wrap-016
break-spaces-003
break-spaces-004
break-spaces-005
break-spaces-006
break-spaces-007
break-spaces-008
break-spaces-009
break-word-004
break-word-005
break-word-006
break-word-007
break-word-008
break-all-010
break-all-011
break-all-012
break-all-013
break-all-014
break-all-015

Implementation in several web engines

During the implementation of a browser feature, even a small one like this, it’s quite usual to find out bugs and interoperability issues. Even though this may slow down the implementation of the feature, it’s also a source of additional Web Platform tests and it may contribute to the robustness of the feature itself and the related CSS properties and values. That’s why I decided to implement the feature in parallel for WebKit (Safari) and Blink (Chrome) engines, which I think it helped to ensure interoperability and code maturity. This approach also helped to get a deeper understanding of the line breaking logic and its design and implementation in different web engines.

I think it’s worth mentioning some of these code architectural differences, to get a better understanding of the work and challenges this feature required until it reached web author’s browser.

Chrome/Blink engine

Lets start with Chrome/Blink, which was especially challenging due to the fact that Blink is implementing a new layout engine (LayoutNG). The implementation for the legacy layout engine was the first step, since it ensures the feature will arrive earlier, even behind an experimental runtime flag.

The legacy layout relies on the BreakingContext class to implement the line breaking logic for the inline layout operations. It has the main characteristic of handling the white space breaking opportunities by its own, instead of using the TextBreakIterator (based on ICU libraries), as it does for determining breaking opportunities between letters and/or symbols. This design implies too much complexity to do even small changes like this, especially because is very sensible in terms of performance impact. In the following diagram I try to show a simplified view of the classes involved and the interactions implemented by this line breaking logic.

The LayoutNG line breaking logic is based on a new concept of fragments, mainly handled by the NGLineBreaker class. This new design simplifies the line breaking logic considerably and it’s highly optimized and adapted to get the most of the TextBreakIterator classes and the ICU features. I tried to show a simplified view of this new design with the following diagram:

In order to describe the work done to implement the feature for this web engine, I’ll list the main bugs and patches landed during this time: CR#956465, CR#952254, CR#944063,CR#900727, CR#767634, CR#922437

Safari/WebKit engine

Although as time passes this is less probable, WebKit and Blink still share some of the layout logic from the ages prior to the fork. Although Blink engineers have applied important changes to the inline layout logic, both code refactoring and optimizations, there are common design patterns that made relatively easy porting to WebKit the patches that implemented the feature for the Blink’s legacy layout. In WebKit, the line breaking logic is also implemented by the BreakingContext class and it has a similar architecture, as it’s described, in a quite simplified way, in the class diagram above (it uses different class names for the render/layout objects, though) .

However, Safari supports for the mac and iOS platforms a different code path for the line breaking logic, implemented in the SimpleLineLayout class. This class provides a different design for the line breaking logic, and, similar to what Blink implements in LayoutNG, is based on a concept of text fragments. It also relies as much as possible into the TextBreakIterator, instead of implementing complex rules to handle white spaces and breaking opportunities. The following diagrams show this alternate design to implement the line breaking process.

This SimpleLineLayout code path in not supported by other WebKit ports (like WebKitGtk+ or WPE) and it’s not available either when using some CSS Text features or specific fonts. There are other limitations to use this SimpleLineLayout codepath, which may lead to render the text using the BreakingContext class.

Again, this is the list of bugs that were solved to implement the feature for the WebKit engine: WK#197277, WK#196169, WK#196353, WK#195361, WK#177327, WK#197278

Conclusion

I hope that at this point these 2 facts are clear now:

  • The white-space: break-spaces feature is a very simple but powerful feature that provides a new line breaking behavior, based on unix-terminal systems.
  • Although it’s a simple feature, on the paper (spec), it implies a considerable amount of work so that it reaches the browser and it’s available for web authors.

In this post I tried to explain in a simple way the main purpose of this new feature and also some interesting corner cases and combinations with other Line Breaking features. The demos I used shown 2 different use cases of this feature, but there are may more. I’m sure the creativity of web authors will push the feature to the limits; by then, I’ll be happy to answer doubts, about the spec or the implementation for the web engines, and of course fix the bugs that may appear once the feature is more used.

Igalia logo
Bloomberg logo

Igalia and Bloomberg working together to build a better web

Finally, I want to thank Bloomberg for supporting the work to implement this feature. It’s another example of how non-browser vendors can influence the Web Platform and contribute with actual features that will be eventually available for web authors. This is the kind of vision that we need if we want to keep a healthy, open and independent Web Platform.

by jfernandez at June 10, 2019 08:11 PM

Google Chrome

Take your achievements with you, Class of 2019

The Class of 2019 can take their achievements with them as they transition to the next phase with Google for Education- their Docs, emails and Drive files as well as with a discount for a new Pixelbook.

June 10, 2019 04:00 PM

June 06, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 76.0.3809.12 for Windows, Mac, and Linux.



A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 06, 2019 01:24 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 76.0.3809.6 (Platform version: 12239.3.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. View changes here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser).


Cindy Bayless
Google Chrome

by Cindy Bayless (noreply@blogger.com) at June 06, 2019 09:14 AM

June 04, 2019

Google Chrome Releases

Chrome for Android Update

Hi, everyone! We've just released Chrome 75 (75.0.3770.67) for Android: it'll become available on Google Play over the next few weeks.

This release contains the following features, as well as stability and performance improvements:
  • Generate strong and unique passwords with Chrome’s built-in password manager
  • Quickly look up your passwords by tapping any password field and using the new keyboard option
You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at June 04, 2019 06:47 PM

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 75 (75.0.3770.75) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at June 04, 2019 04:26 PM

Stable Channel Update for Desktop

The Chrome team is delighted to announce the promotion of Chrome 75 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks.

Chrome 75.0.3770.80 contains a number of fixes and improvements -- a list of changes is available in the log. Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 75.

Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 42 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

[$5000][956597] High CVE-2019-5828: Use after free in ServiceWorker. Reported by leecraso of Beihang University and Guang Gong of Alpha Team, Qihoo 360 on 2019-04-25
[$500][958533] High CVE-2019-5829: Use after free in Download Manager. Reported by Lucas Pinheiro, Microsoft Browser Vulnerability Research on 2019-05-01
[$TBD][665766] Medium CVE-2019-5830: Incorrectly credentialed requests in CORS. Reported by Andrew Krasichkov, Yandex Security Team on 2016-11-16
[$TBD][950328] Medium CVE-2019-5831: Incorrect map processing in V8. Reported by yngwei(JiaWei, Yin) of IIE Varas and sakura of Tecent Xuanwu Lab on 2019-04-07
[$TBD][959390] Medium CVE-2019-5832: Incorrect CORS handling in XHR. Reported by Sergey Shekyan (Shape Security) on 2019-05-03
[$N/A][945067] Medium CVE-2019-5833: Inconsistent security UI placement. Reported by Khalil Zhani on 2019-03-23
[$N/A][962368] Medium CVE-2019-5834: URL spoof in Omnibox on iOS. Reported by Khalil Zhani on 2019-05-13
[$1000][939239] Medium CVE-2019-5835: Out of bounds read in Swiftshader. Reported by Wenxiang Qian of Tencent Blade Team on 2019-03-07
[$1000][947342] Medium CVE-2019-5836: Heap buffer overflow in Angle. Reported by Omair on 2019-03-29
[$500][918293] Medium CVE-2019-5837: Cross-origin resources size disclosure in Appcache . Reported by Adam Iwaniuk on 2018-12-30
[$500][893087] Low CVE-2019-5838: Overly permissive tab access in Extensions. Reported by David Erceg on 2018-10-08
[$500][925614] Low CVE-2019-5839: Incorrect handling of certain code points in Blink. Reported by Masato Kinugawa on 2019-01-26
[$N/A][951782] Low CVE-2019-5840: Popup blocker bypass. Reported by Eliya Stein, Jerome Dangu on 2019-04-11

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:

  • [970244] Various fixes from internal audits, fuzzing and other initiatives






Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Thank you,

Srinivas Sista

by Srinivas Sista (noreply@blogger.com) at June 04, 2019 02:00 PM

Beta Channel Update for Desktop

The beta channel has been updated to 75.0.3770.80 for Windows, Mac, and, Linux.


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at June 04, 2019 11:12 AM

May 31, 2019

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 76.0.3807.0 (Platform version: 12236.0.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. View changes here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser).


Cindy Bayless
Google Chrome

by Cindy Bayless (noreply@blogger.com) at May 31, 2019 10:51 AM