Planet Chromium

August 14, 2018

Google Chrome Releases

Stable Channel Update for Chrome OS



The Stable channel has been updated to 68.0.3440.87 (Platform version: 10718.71.2/3) for most Chrome OS devices. This build contains a number of bug fixes and security updates. Systems will be receiving updates over the next several days.
New Features
  • 802.11r Fast BSS Transition Support
  • Ability to use Select to Speak with touch/stylus only
  • Admin policy to enable/disable adding of native printers client side
  • Enabling/disabling ChromeVox through the side volume keys (tablets/convertibles)
  • High resolution image support in camera app
  • Introduction of Display Size settings
  • Material 2.0 dialogs and secondary UI on ChromeOS
  • Overview visual refresh and motion spec improvements
  • PIN sign-in support
  • Select-to-Speak ability to select specific text to be read aloud by highlighting the text, then pressing Search + s. This works in addition to the original behavior of pressing Search and clicking an item or dragging a box around content to be read aloud.
  • Support Child account as first sign-in
  • Two new shortcuts to toggle the magnifiers on/off

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).

Bernie Thompson
Google Chrome

by Bernie Thompson (noreply@blogger.com) at August 14, 2018 04:13 PM

Hangouts Meet Hardware Update

The stable channel has been updated to Chrome OS 67 for Hangouts Meet hardware and Chrome devices for Meetings. Systems will be receiving updates over the next several days.

In addition to Chrome OS bug fixes and security updates, this update contains the latest Huddly firmware 1.3.2, featuring:


  • Tuned exposure based on user studies
  • Improved color accuracy
  • Optimization in power consumption


For more information about this release, along with known issues and bug fixes checkout the Hangouts Meet hardware and Chrome OS release notes.

Kota Hisamatsu
Hangouts Meet hardware

by Kota Hisamatsu (noreply@blogger.com) at August 14, 2018 03:52 PM

Dev Channel Update for Desktop

The dev channel has been updated to 70.0.3521.2 for Windows, Mac & 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 August 14, 2018 11:49 AM

August 13, 2018

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 69.0.3497.35 (Platform version: 10895.21.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found 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 August 13, 2018 05:25 PM

August 09, 2018

Igalia Chromium

Manuel Rego: Changes on CSS Grid Layout in percentages and indefinite height

This is a blog post about a change of behavior on CSS Grid Layout related to percentage row tracks and gutters in grid containers with indefinite height. Igalia has just implemented the change in Chromium and WebKit, which can affect some websites out there. So here I am going to explain several things about how percentages work in CSS and all the issues around it, of course I will also explain the change we are doing in Grid Layout and how to keep your previous behavior in the new version with very simple changes.

Sorry for the length but I have been dealing with these issues since 2015 (probably earlier but that is the date of the first commit I found about this topic), and I went too deep explaining the concepts. Probably the post has some mistakes, this topic is not simple at all, but it represents a kind of brain dump of my knowledge about it.

Percentages and definite sizes

This is the easy part, if you have an element with fixed width and height resolving percentages on children dimensions is really simple, they are just computed against the width or height of the containing block.

A simple example:

<div style="width: 500px; height: 200px; border: dashed thick black;">
  <div style="width: 50%; height: 75%; background: magenta;"></div>
</div>

Example of percentage dimensions in a containing block with definite sizes Example of percentage dimensions in a containing block with definite sizes

Things are a bit trickier for percentage margins and paddings. In inline direction (width in horizontal writing mode) they work as expected and are resolved against the inline size. However in block direction (height) they are not resolved against the block size (as one can initially expect) but against the inline size (width) of the containing block.

Again a very simple example:

<div style="width: 500px; height: 200px; border: dashed thick black;">
  <div style="margin-left: 10%; margin-top: 10%;
              height: 150px; background: magenta;"></div>
</div>

Example of percentage margins in a containing block with definite sizes Example of percentage margins in a containing block with definite sizes

Note that there is something more here, in both Flexbox and Grid Layout specifications it was stated in the past that percentage margins and paddings resolve against their corresponding dimension, for example inline margins against inline axis and block margins against block axis.

This was implemented like that in Firefox and Edge, but Chromium and WebKit kept the usual behavior of resolving always against inline size. So for a while the spec had the possibility to resolve them in either way.

This was a source of interoperability issues between the different browsers but finally the CSS Working Group (CSSWG) resolved to keep the behavior for regular blocks also for flex and grid items. And both Firefox and Edge modified their behavior and all browsers have the same output nowadays.

Percentages and indefinite sizes

First question is, what is an indefinite size? The simple answer is that a definite size is a size that you can calculate without taking into account the contents of the element. An indefinite size is the opposite, in order to compute it you need to check the contents first.

But then, what happens when the containing block dimensions are indefinite? For example, a floated element has indefinite width (unless otherwise manually specified), a regular block has indefinite height by default (height: auto).

For heights this is very simple, percentages are directly ignored so they have no effect on the element, they are treated as auto.

For widths it starts to get funny. Web rendering engines have two phases to compute the width of an element. A first one to compute the minimum and maximum intrinsic width (basically the minimum and maximum width of its contents), and a second one to compute the final width for that box.

So let’s use an example to explain this properly. Before getting into that, let me tell you that I am going to use Ahem font in some examples, as it makes very easy to know the size of the text and resolve the percentages accordingly, so if we use font: 50px/1 Ahem; we know that the size of an X character is a square of 50x50 pixels.

<div style="float: left; font: 50px/1 Ahem;
            border: solid thick black; background: magenta; color: cyan;">
  XX XXXXX
</div>

Example of intrisic width without constraints Example of intrisic width without constraints

The browser first calculates the intrinsic width, as minimum it computes 250px (the size of the smallest word, XXXXX in this case), as maximum size it would be 400px (the size of the whole text without line breaking XX XXXXX). So after this phase the browser knows that the element should have a width between 250px and 400px.

Then during layout phase the browser will decide the final size, if there are no constraints imposed by the containing block it will use the maximum intrinsic width (400px in this case). But if you have a wrapper with a 300px width, the element will have to use 300px as width. If you have a wrapper smaller than the minimium intrinsic width, for example 100px, the element will still use the minimum 250px as its size. This is a quick and dirty explanation, but I hope it is useful to get the general idea.

Example of intrisic width width different constraints Example of intrisic width with different constraints

In order to resolve percentage widths (in the indefinite width situations) the browser does a different thing depending on the phase. During intrinsic size computations the percentage width is ignored (treated as auto like for the heights). But in the layout phase the width is resolved against the intrinsic size computed earlier.

Trying to summarize the above paragraphs, we can say that somehow the width is only indefinite while the browser is computing the intrinsic width of the element, afterwards during the actual layout the width is considered definite and percentages are resolved against it.

So now let’s see an example of indefinite dimensions and percentages:

<div style="float: left;
            border: solid thick black; background: magenta;">
  <div style="width: 50%; height: 50%; background: cyan;">Hello world!</div>
</div>

Example of percentage dimensions in a containing block with indefinite sizes Example of percentage dimensions in a containing block with indefinite sizes

First the size of the magenta box is calculated based on its contents, as it has not any constraint it uses the maximum intrinsic width (the length of Hello world!). Then as you can see the width of the cyan box is 50% of the text length, but the height is the same than if we use height: auto (the default value), so the 50% height is ignored.

Back-compute percentages

For margins and paddings things work more or less the same, remember that all of them are resolved against the inline direction (so they are ignored during intrinsic size computation and resolved later during layout).

But there is something special about this too. Nowadays all the browsers have the same behavior but that was not always the case, not so long time ago (before Firefox 61 which was released past June) things worked different in Firefox than the rest of browsers

Again let’s go to an example:

<div style="float: left; font: 50px/1 Ahem;
            border: solid thick black; background: magenta;">
  <div style="margin-left: 50%; height: 100px;
              background: cyan; color: blue;">XXXXX</div>
</div>

Example of percentage margins in a containing block with indefinite sizes Example of percentage margins in a containing block with indefinite sizes

In this example the size of the magenta box (the floated div) is the width of the text, 250px in this case. Then the margin is 50% of that size (125px), making that the size of the cyan box gets reduced to 125px too, which causes overflow.

But for these cases (percentage width margins and paddings and indefinite width container) Firefox did something extra that was called back-compute percentages. For that it something similar to the following formula:

Intrinsic width / (1 - Sum of percentages)

Which for this case would be 250px / (1 - 0.50) = 500px. So it takes as intrinsic size of the magenta box 500px, and then it resolves the 50% margin against it (250px). Thanks to this there is no overflow, and the margin is 50% of the containing block size.

Example of old Firefox behavior back-computing percentage margins Example of old Firefox behavior back-computing percentage margins

This Firefox behavior seems really smart and avoid overflows, but the CSSWG discussed about it and decided to use the other behavior. The main reason is what happens when you are around 100% percentages, or if you go over that value. The size of the box starts to be quite big (with 90% margin it would be 2500px), and when you go to 100% or over it you cannot use that formula so it considers the size as infinity (basically the viewport size in this example) and there is discontinuity in how percentages are resolved.

So after that resolution Firefox changed their implementation and removed the back-computing percentages logic, thus we have now interoperability in how percentage margins and paddings are resolved.

CSS Grid Layout and percentages

And now we arrive to CSS Grid Layout and how to resolve percentages in two places: grid tracks and grid gutters.

Of course when the grid container has definite dimensions there are no problems in resolving percentages against them, that is pretty simple.

As usual the problem starts with indefinite sizes. Originally this was not a controversial topic, percentages for tracks were behaving similar to percentage for dimensions in regular blocks. A percentage column was treated as auto for intrinsic size computation and later resolved against that size during layout. For percentage rows they were treated as auto. It does not mean that this is very easy to understand (actually it took me a while), but once you get it, it is fine and not hard to implement.

But when percentage support was added to grid gutters the big party started. Firefox was the first browser implementing them and they decided to use the back-compute technique explained in the previous point. Then when we add support in Chromium and WebKit we did something different than Firefox, we basically mimic the behavior of percentage tracks. As browsers started to diverge different discussions appear.

One of the first agreements on the topic was that both percentage tracks and gutters should behave the same. That invalidated the back-computing approach, as it was not going to work fine for percentage tracks as they have contents. In addition it was finally discarded even for regular blocks, as commented earlier, so this was out of the discussion.

However the debate moved to how percentage row tracks and gutters should be resolved, if similar to what we do for regular blocks or if similar to what we do for columns. The CSSWG decided they would like to keep CSS Grid Layout as symmetric as possible, so making row percentages resolve against the intrinsic height would achieve that goal

So finally the CSSWG resolved to modify how percentage row tracks and gutters are resolved for grid containers with indefinite height. The two GitHub issues with the last discussions are: #509 and #1921.

Let’s finish this point with a pair of examples to understand the change better comparing the previous and new behavior.

Percentage tracks:

<div style="display: inline-grid; border: solid thick;
            grid-template-columns: 75%; grid-template-rows: 50%;">
  <div style="background: magenta;">Testing</div>
</div>

Example of percentage tracks in a grid container with indefinite sizes Example of percentage tracks in a grid container with indefinite sizes

Here the intrinsic size of the grid container is the width and height of the text Testing, and then the percentages tracks are resolved against that size for both columns and rows (before that was only done for columns).

Percentage gutters:

<div style="display: inline-grid; grid-gap: 10%; border: solid thick;
            grid-template-columns: 200px 200px; grid-template-rows: 100px 100px;">
  <div style="background: magenta;"></div>
  <div style="background: cyan;"></div>
  <div style="background: yellow;"></div>
  <div style="background: lime;"></div>
</div>

Example of percentage gutters in a grid container with indefinite sizes Example of percentage gutters in a grid container with indefinite sizes

In this example we can see the same thing, with the new behavior both the percentage column and row gaps are resolved against the intrinsic size.

Change behavior for indefinite height grid containers

For a while all browsers were behaving the same (after Firefox dropped the back-computing approach) so changing this behavior would imply some kind of risks, as some websites might be affected by that and get broken.

For that reason we added a use counter to track how many websites where hitting this situation, using percentage row tracks in a indefinite height grid container. The number is not very high, but there is an increasing trend as Grid Layout is being adopted (almost 1% of websites are using it today).

And then Firefox changed the behavior for percentage row gutters to follow the new text on the spec, so they are resolved against the intrinsic height (this happened in version 62). However it did not change the behavior for percentage row tracks yet.

This was a trigger to retake the topic and go deeper on it, after analyzing it carefully and crafting a prototype implementation we sent an intent to implement and ship to blink-dev mailing list.

The intent was approved, but we were requested to analyze the sites that were hitting the use counter. After checking 178 websites only 8 got broken due to this change, we contacted them to try to get them fixed explaining how to keep the previous behavior (more about this in next point). You can find more details about this research in this mail.

Apart from that we added a deprecation message in Chromium 69, so if you have a website that is affected by this (it does not mean that it has to get broken but that it uses percentage row tracks in a grid container with indefinite height) you will get the following warning in the JavaScript console:

[Deprecation] Percentages row tracks and gutters for indefinite height grid containers will be resolved against the intrinsic height instead of being treated as auto and zero respectively. This change will happen in M70, around October 2018. See https://www.chromestatus.com/feature/6708326821789696 for more details.

Finally this week the patch has been accepted and merged in master, so since Chromium 70.0.3516 (current Canary) you will have the new behavior. Apart from that we also make the fix in WebKit that will be hopefully part of the next Safari releases.

In addition Firefox and Edge developers have been notified and we have shared the tests in WPT as usual, so hopefully those implementations will get updated soon too.

Update your website

Yes this change might affect your website or not, even if you get the deprecation warning it can be the case that your website is still working perfectly fine, but in some cases it can break quite badly. The good news is that the solution is really straightforward.

If you find issues in your website and you want to keep the old behavior you just need to do the following for grid containers with indefinite height:

  • Change percentages in grid-template-rows or grid-auto-rows to auto.
  • Modify percentages in row-gap or grid-row-gap to 0.

With those changes your website will keep behaving like before. In most cases you will realize that the percentages were unneeded and were not doing anything useful for you, even you would be able to drop the declaration completely.

One of these cases would be websites that have grid containers with just one single row of 100% height (grid-template-rows: 100%), many of the sites hitting the use counter are like this. All these are not affected by this change, unless the have extra implicit rows, but the 100% is not really useful at all there, they can simply remove the declaration.

Another sites that have issues are the ones that have for example two rows that sum up 100% in total (grid-template-rows: 25% 75%). These percentages were ignored before, so the contents always fit in each of the rows. Now the contents might not fit in each row and the results might not be the desired ones. Example:

<div style="display: grid; grid-template-rows: 25% 75%; border: solid thick;">
  <div style="background: magenta;">First<br>two lines</div>
  <div style="background: cyan;">Second</div>
</div>

Example of overlapping rows in the new behavior Example of overlapping rows in the new behavior

The sites that were more broken usually have several rows and used percentages only for a few of them or for all. And now the rows overflow the height of the grid container and they overlap other content on the website. There were cases like this example:

<div style="display: grid; grid-template-rows: 50%; border: solid thick;">
  <div style="background: magenta;">First</div>
  <div style="background: cyan; height: 200px;">Second</div>
  <div style="background: yellow; height: 100px;">Third</div>
</div>

Example of overflowing rows in the new behavior Example of overflowing rows in the new behavior

Closing

This topic has been a kind of neverending story for the CSSWG, but finally it seems we are reaching to an end. Let’s hope this does not get any further and things get settle down after all this time. We hope that this change is the best solution for web authors and everyone will be happy with the final outcome.

As usual I could not forget to highlight that all this work has been done by Igalia thanks to Bloomberg sponsorship as part of our ongoing collaboration.

Igalia and Bloomberg working together to build a better web Igalia and Bloomberg working together to build a better web

Thanks for reading that long, this ended up being much more verbose and covering more topics than originally planned. But I hope it can be useful to understand the whole thing. You can find all the examples from this blog post in this pen feel free to play with them.

And to finish this blog post I could only do it by quoting fantasai:

this is why I hate percentages in CSS

I cannot agree more with her. 😇

August 09, 2018 10:00 PM

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 69.0.3497.32 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.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at August 09, 2018 12:20 PM

August 08, 2018

Chromium Blog

Chrome 69 Beta: CSS tricks, and more

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 69 on ChromeStatus.com. Chrome 69 is beta as of August 2.

New CSS tricks

Chrome has added several new CSS features.

Conic gradients

CSS conic (angular/sweep) gradients allow color transitions around a center rather than radiating from it. This allows, for example, creating a hue wheel using only two CSS properties as shown below. More examples are available.


div {
background: conic-gradient(red, yellow, lime, aqua, blue, magenta, red);
border-radius: 50%
}

New margin, padding, and border properties

Logical margin, padding, and border properties now use standard names, specifically margin-{block,inline}-{start,end}, padding-{block,inline}-{start,end} and border-{block,inline}-{start,end}-{width,style,color}. These capabilities were previously supported through -webkit prefixes and non-standard names. Shorthand properties are only added for border-{block,inline}-{start,end}.

CSS scroll snap

CSS scroll snap positions are offsets in a scroll container's visual viewport where scrolling will stop after each scrolling operation. This improves the user experience by allowing scrollable zones to easily stop at predefined points. This also enables common UX scroll patterns without the need for JavaScript. One such pattern is a horizontal image carousel accomplished with the declarations below. The article Well-Controlled Scrolling with CSS Scroll Snap provides more depth.


#gallery {
scroll-snap-type: x mandatory;
overflow-x: scroll;
display: flex;
}

#gallery img {
scroll-snap-align: center;
}

Display cutouts

Display cutouts are now supported in Chrome through the new CSS env() function (environment variables) and the viewport-fit meta tag. This allows developers to take advantage of the entire screen on devices that have a display cutout.

For example, to tell the browser to expand into the display cutout area the site should set the viewport-fit property in the viewport meta tag to cover. The site can then use the safe area inset CSS environment variables to layout their content without being covered by the cutout. This is shown below. The explainer and the spec provide more information.


<meta name="viewport" content="viewport-fit: cover" />

<style>
#box {
margin-top: env(safe-area-inset-top);
margin-left: env(safe-area-inset-left);
margin-bottom: env(safe-area-inset-bottom);
margin-right: env(safe-area-inset-right);
}
</style>

<div id=box></div>

Other features in this release

Canvas

OffscreenCanvas is a new interface that allows 2D and WebGL canvas rendering contexts to be used in Workers. This increases parallelism in web applications and improves performance on multi-core systems.

Chrome now also supports DedicatedWorker.requestAnimationFrame(), allowing animation-like events to be triggered the same on dedicated workers as they are in Window. For example:


const offscreenCanvas = new OffscreenCanvas(100, 100);
const ctx = offscreenCanvas.getContext("2d");
ctx.fillRect(0, 0, 10, 10);

Or together with canvas:

const canvasElement = document.getElementById("mycanvas")
const offscreenCanvas = canvasElement.transferControlToOffscreen();
const ctx = offscreenCanvas.getContext("2d");
ctx.fillRect(0, 0, 10, 10);

Inside a worker:

self.onmessage = function(ev) {
const offscreenCanvas = ev.data;
const ctx = offscreenCanvas.getContext("2d");
let x = 0;
const draw = function() {
ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
ctx.fillRect(x, 0, 10, 10);
x = (x + 1) % ctx.canvas.width;
requestAnimationFrame(draw);
};
draw(0);
}

Main page:

const worker = new Worker("worker.js");
const offscreenCanvas =
document.getElementById("canvas").transferControlToOffscreen();
worker.postMessage(offscreenCanvas, [offscreenCanvas]);

DOM

A new method named Element.toggleAttribute() allows toggling the existence of an element's attribute in a way similar to Element.classList.toggle. An optional force parameter forces addition or deletion of the attribute depending on the value of force. This makes managing boolean attributes much simpler as the interface doesn't use strings as does Element.setAttribute().

Fetch API: Request.isHistoryNavigation

A boolean property has been added to request objects to indicate whether a particular request is a history navigation. This allows a service worker to know whether a request was due to a back/forward navigation. An example of how this might be used is that a service worker could respond to such a navigation with a cached response.

JavaScript APIs

JavaScript has several new APIs:
  • The ReportingObserver API provides a JavaScript callback function invoked in response to deprecations and browser interventions. The report can be saved, sent to the server, or or handled using arbitrary JavaScript. This feature is designed to give developers greater insight into the operation of their sites on real-world devices.
  • JavaScript arrays are getting two new methods. Array.prototype.flat() returns a new array with all sub-array elements concatenated into it recursively up to the specified depth. The sub-array elements become members of the new array. Array.prototype.flatMap() first maps each element using a mapping function, then flattens the result into a new array. This method is functionally equivalent to a map followed by calling flat() with a depth of 1.

Keyboard Map API

Some applications such as games assign specific functions to specific physical keys. When the interface references these keys it needs to show either the character displayed on the key, which varies by locale, or the character assigned to the key by an alternate keyboard layout that may have been installed by the user. Because of these layout variations it's sometimes possible for the character shown in the interface to not reference the intended physical key.
This new API provides a way to translate KeyboardEvent.code values representing physical keys into correct strings for display to the user. You can find details and examples of this new API in the specification and the explainer.

Loader

Support for the "rtt", "downlink", and "ect" client hint values and HTTP request headers have been added to Chrome to convey a device's network connection speed to servers. For example, the rtt client hint provides the server with the estimated effective round-trip time of the current connection, rounded to the nearest multiple of 25 milliseconds.The server could use this serve a downsampled image if the connection speed is slower than expected. These network quality hints provide to the server the same values as provided to a web page by the Network Information APIs navigator.connection.rtt, navigator.connection.downlink, and navigator.connection.effectiveType.

Media: Querying encryption scheme support through EME

Some platforms or key systems only support AES-128 in CTR mode, while others only support CBCS mode. Still others are able to support both. A new method allows web developers to query whether a specific encryption scheme is supported by Encrypted Media Extensions (EME).

Mid-ligature text selection

Chrome now allows for text to be selected inside ligatures. (A ligature is a combination of two or more letters in a single symbol.) This includes both mouse selection as well as cursor selection in input and textarea elements. We have also changed slightly the way we render text selection to support this change. Parts of text that happen to lie outside the selection area are now rendered with the original style:


Selection in a ligature in English.

Selection in a ligature in Arabic.

Performance

To avoid leaking information between frames, performance.memory values are currently heavily quantized, and delayed by 20 minutes.
If the renderer process is locked to documents from a single site (as in the case of Site Isolation on desktop), we can expose this information with fewer concerns about leaking information between frames. In these cases, we'll not return quantized memory consumption information, delayed by 30 seconds. This allows developers to detect performance regressions from user data more easily because the memory measurements will be more accurate and can be taken more frequently.

ServiceWorker

Service workers have two improvements:
  • ServiceWorkerRegistration.update() previously resolved with undefined. Now it resolves to the registration object as required by the specification.
  • Because of a technical limitation, navigator.serviceWorker previously threw a SecurityError when accessed on an insecure context. After this change, navigator.serviceWorker returns undefined
. This aligns with the specification.

Update behavior of CSS Grid Layout percentage row tracks and gutters

In a future release there will be a change to how percentage row tracks and gutters are resolved on grid containers with indefinite height. Currently they behave similar to percentage heights in regular blocks, but going forward they will behave the same as for columns, making them symmetric.
Percentages will be ignored when computing intrinsic height (like it happens now) and resolved afterwards against that height. That way both column and row axes will have a symmetric behavior in order to resolve tracks and gutters specified by percentages.
In Chrome 69 you'll get a warning in the JavaScript console about this change. If you want to keep the current behavior in Chrome 70 you need to replace your percentage row tracks and gutters in indefinite height grid containers by "auto" and "0px" respectively.

Web Locks API

The Web Locks API allows scripts running in one tab to asynchronously acquire a lock, hold it while work is performed, then release it. While held, no other script executing in the same origin can acquire the same lock. A lock represents some potentially shared resource, identified by a name chosen by the web app. For example, if a web app running in multiple tabs wants to ensure that only one tab is syncing to the network, each tab could try to acquire a my_net_sync lock, but only one tab will succeed.
An example is shown below. It shows a function called when a lock for my_resource is acquired.

await navigator.locks.request('my_resource', async lock => {
const url = await look_up_in_database();
const response = await fetch(url);
const body = await response.text();
await store_body_in_database(body);
});

For more details about the API methods and options, see the explainer and draft specification.

Web Authentication now supports CTAP2 FIDO devices

Web Authentication adds support for CTAP2 devices, which provide advanced security capabilities such as biometric authentication and resident keys (keys stored on the device). The WebAuthentication API formerly only supported Universal 2nd Factor (U2F) devices at the transport layer. This change doesn't alter the API surface itself, but enables richer device interactions via the existing Web Authentication API.

WebRTC

WebRTC has two improvements:
  • Chrome now supports the RTCRtpParameters.headerExtensions dictionary entry which is returned by RTCRtpSender.getParameters(). This is a read-only field that allows inspection of the parameters that are set on a PeerConnection after negotiation.
  • The RTCRtpSender and RTCRtpReceiver interfaces now provide the getCapabilities() method
which returns the most optimistic view of the capabilities of the system for sending media of the given kind. It does not reserve any resources, ports, or other state but is meant to provide a way to discover the types of capabilities of the browser including which codecs or RTP extensions may be supported.

Deprecations and Interoperability Improvements

Chrome sometimes deprecates, removes, or changes features to increase interoperability with other browsers. This version of Chrome includes the following such changes.

Removal of 'stalled' event from HTMLMediaElements that use Media Source Extensions

Previously, the HTMLMediaElement.stalled event fired when media download has failed to progress for at least 3 seconds. In Media Source Extensions, the web app manages the download and the media element is not aware of its progress. Since some apps append media data in chunks larger than 3 seconds, stalled was being fired at inappropriate times. To solve this, stalled has been removed for Media Source Extensions.

Removal of document.createTouchList

The document.createTouchList() method was removed
in favor of the Touch() constructor which has been supported since Chrome 48.

The window.confirm() method no longer activates its parent tab

If a document in a background tab calls window.confirm(), it returns immediately with false, and no dialog is shown to the user. If the tab is active, then the call shows a dialog as normal. Specifically, this removes the ability to use window.confirm() to bring a tab to the front because this is rarely what the user wants.

by Chrome Blog (noreply@blogger.com) at August 08, 2018 02:57 PM

Google Chrome Releases

Stable Channel Update for Desktop

The stable channel has been updated to 68.0.3440.106 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.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at August 08, 2018 12:28 PM

August 07, 2018

Igalia Chromium

Manuel Rego: CSS Logical Properties and Values in Chromium and WebKit

Since the beginning of the web we have been used to deal with physical CSS properties for different features, for example we all know how to set a margin in an element using margin-left, margin-right, margin-top and/or margin-bottom. But with the appearance of CSS Writing Modes features, the concepts of left, right, top and bottom have somehow lost their meaning.

Imagine that you have some right-to-left (RTL) content on your website your left might be probably the physical right, so if you are usually setting margin-left: 100px for some elements, you might want to replace that with margin-right: 100px. But what happens if you have mixed content left-to-right (LTR) and RTL at the same time, then you will need different CSS properties to set left or right depending on that. Similar issues are present if you think about vertical writing modes, maybe left for that content is the physical top or bottom.

CSS Logical Properties and Values is a CSS specification that defines a set of logical (instead of physical) properties and values to prevent this kind of issues. So when you want to set that margin-left: 100px independently of the direction and writing mode of your content, you can directly use margin-inline-start: 100px that will be smart enough. Rachel Andrew has a nice blog post explaining deeply this specification and its relevance.

Example of 'margin-inline-start: 100px' in different combinations of directions and writing modes Example of margin-inline-start: 100px in different combinations of directions and writing modes

Oriol Brufau, an active collaborator on the CSS Working Group (CSSWG), has been doing a Igalia Coding Experience implementing support for CSS Logical Properties and Values in Blink and WebKit. Maybe you were already aware of this as my colleague Frédéric Wang already talked about it in his last blog post reviewing the activities of Igalia Web Platform team in the past semester.

Some history

Chromium and WebKit have had support since a long time ago for some of the CSS logical properties defined by the spec. But they were not using the standard names defined in the specification but some -webkit- prefixed ones with different names.

For setting the dimensions of an element Chromium and WebKit have properties like -webkit-logical-width and -webkit-logical-height. However CSS Logical defines inline-size and block-size instead. There are also the equivalent ones for minimum and maximum sizes too. These ones have been already unprefixed at the beginning of 2017 and included in Chromium since version 57 (March 2017). In WebKit they are still only supported using the prefixed version.

But there are more similar properties for margins, paddings and borders in Chromium and WebKit that use start and end for inline direction and before and after for block direction. In CSS Logical we have inline-start and inline-end for inline direction and block-start and block-end for block direction, which are much less confusing. There was an attempt in the past to unprefix these properties but the work was abandoned and never completed. These ones were still using the -webkit- prefix so we decided to tackle them as the first task.

The post has been only talking about properties so far, but the same thing applies to some CSS values, that is why the spec is called CSS Logical Properties and Values. For example a very well-known property like float has the physical values left and right. The spec defines inline-start and inline-end as the logical values for float. However these were not supported yet in Chromium and WebKit, not even using -webkit- prefixes.

Firefox used to have some -moz- prefixed properties, but since Firefox 41 (September 2015) it is shipping many of the standard logical properties and values. Firefox has been using these properties extensively in its own tests, thus having them supported in Chromium will make easier to share them.

At the beginning of this work, Oriol wrote a document in which explaining the implementation plan where you can check the status of all these properties in Chromium and Firefox.

Unprefix existent properties

We originally send an intent to implement and ship for the whole spec, actually not all the spec but the parts that the CSSWG considered ready to implement. But Chromium community decided it was better to split it in two parts:

The work on the first part, making the old -webkit- prefixed properties to use the new standard names, has been already completed by Oriol and it is going to be included in the upcoming release of Chromium 69.

In addition to the Chromium work Oriol has just started to do this on WebKit too. Work is on early stages here but hopefully things will move forward in parallel to the Chromium stuff.

Adding support for the rest

Next step was to add support for the new stuff behind an experimental flag. This work is ongoing and you can check the current status in the latest Canary enabling the Experimental Web Platform features flag.

So far Oriol has added support for a bunch of shorthands and the flow-relative offset properties. You can follow the work in issue #850004 in Chromium bug tracker.

We will talk more about this in a future blog post once this task is completed and the new logical properties and values are shipped.

Tests!

Of course testing is a key part of all these tasks, and web-platform-tests (WPT) repository plays a fundamental role to ensure interoperability between the different implementations. Like we have been doing in Igalia lately in all our developments we used WPT as the primary place to store all the tests related to this work.

Oriol has been creating tests in WPT to cover all these features. Initial tests were based in the ones already available in Firefox and modified them to adapt to the rest of stuff that needs to be checked.

Note that in Chromium all the sideways writing modes test cases are failing as there is no support for sideways in Chromium yet.

Plans for the future

As explained before, this is an ongoing task but we already have some extra plans for it. These are some of the tasks (in no particular order) that we would like to do in the coming months:

  • Complete the implementation of CSS Logical Properties and Values in Chromium. This was explained in the previous point and is moving forward at a good pace.
  • Get rid of usage of -webkit- prefixed properties in Chromium source code. Oriol has also started this task and is currently work in progress.
  • Deprecate and remove the -webkit- prefixed properties. It still too early for that but we will keep an eye on the metrics and do it once usage has decreased.
  • Implement it in WebKit too, first by unprefixing the current properties (which has been already started) and later continuing with the new things. It would be really nice if WebKit follows Chromium on this. Edge also has plans to add support for this spec, so that would make logical properties and values available in all the major browsers.

Wrap up

Oriol has been doing a good job here as part of his Igalia Coding Experience. Apart from all the new stuff that is landing in Chromium, he has also been fixing some related bugs.

We have just started the WebKit tasks, but we hope all this work can be part of future Chromium and Safari releases in the short term.

And that is all for now, we will keep you posted! 😉

August 07, 2018 10:00 PM

Google Chrome

Your Google for Education Guide for Back to School

This back to school season, we’re inspiring educators to teach creatively, efficiently and innovatively with new tools and features from Google for Education.

August 07, 2018 03:00 PM

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 70.0.3514.0 for Windows & Linux, and 70.0.3514.2 for Mac.  


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 August 07, 2018 03:39 PM

Chrome for Android Update

Good news, everyone!  Chrome 68 (68.0.3440.91) for Android has been released and will be available on Google Play over the course of the next few weeks. This release includes a crash fix for a suspected CPU issue.

A list of the changes in this build is available in the Git log.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Estelle Yomba
Google Chrome

by Estelle Yomba (noreply@blogger.com) at August 07, 2018 10:55 AM

August 03, 2018

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 70.0.3510.0 for Mac & Linux, and 70.0.3510.2 for Windows.  


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 August 03, 2018 01:04 PM

August 02, 2018

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 68.0.3440.87 (Platform version: 10718.71.2) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.

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).

Bernie Thompson
Google Chrome

by Bernie Thompson (noreply@blogger.com) at August 02, 2018 05:12 PM

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 69 to the beta channel for Windows, Mac and Linux. Chrome 69.0.3497.23 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.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at August 02, 2018 12:34 PM

August 01, 2018

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 69.0.3497.23 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 August 01, 2018 01:35 PM

July 31, 2018

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 69.0.3497.21 (Platform version: 10895.10.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found 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 July 31, 2018 05:27 PM

Stable Channel Update for Desktop

The stable channel has been updated to 68.0.3440.84 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.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at July 31, 2018 02:58 PM

July 30, 2018

Google Chrome

Browse the web in VR: Chrome launches on Daydream View

Browse the web in VR: Chrome launches on Google Daydream View

July 30, 2018 05:00 PM

July 27, 2018

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 69.0.3497.14 (Platform version: 10895.5.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found 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 July 27, 2018 08:50 AM

July 26, 2018

Chromium Blog

Bringing Google Pay to PaymentRequest

In September 2016 Chrome launched support for the PaymentRequest API, which offers a secure, seamless checkout experience built right into the browser. As part of that launch, Chrome offered support for the basic-card payment method. This allowed users to pay for goods online via PaymentRequest with credit or debit cards stored locally in Chrome or, for signed-in users, stored within their Google Account.

As of version 70, Chrome will no longer return cards stored in a user’s Google Account as part of the basic-card payment method. To continue getting access to cards stored in a user’s Google Account, developers will need to add support for Google Pay. This change is due to the fact that beginning with version 68, Chrome supports the Payment Handler API, a standards-based way for the browser to communicate with digital payment providers. Google Pay supports this standard.

Getting started with Google Pay is easy. Visit the developer site for a quick tutorial and review the latest Google Pay brand guidelines for best practices. When you are ready to implement, just follow the detailed checklist to test your integration and request production access.

You can find troubleshooting tips for common issues and can contact the Google Pay team if you need any additional help. Thanks for helping us make payments on the web a great experience for users everywhere.

Posted by Zach Koch, Product Manager

by Chrome Blog (noreply@blogger.com) at July 26, 2018 11:32 AM

July 25, 2018

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 69.0.3497.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 July 25, 2018 12:18 PM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 68.0.3440.76 (Platform version: 10718.63.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.

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).

Bernie Thompson
Google Chrome

by Bernie Thompson (noreply@blogger.com) at July 25, 2018 10:22 AM