Salvo indicação em contrário, as mudanças descritas abaixo se aplicam à versão mais recente do Canal Beta do Chrome para Android, Chrome OS, Linux, macOS e Windows. Veja a lista completa dos recursos do Chrome 68 no chromestatus.com. O Chrome 68 está na versão beta desde 7 de junho de 2018.


Novo comportamento de adicionar à tela inicial para Progressive Web Apps

Ouvimos os desenvolvedores pedindo mais controle sobre como e quando a opção de adicionar à tela inicial aparece. A partir do Chrome 68 no Android, o comportamento mudou para dar mais controle sobre o momento em que essa opção é exibida. Agora os desenvolvedores podem agregar mais contexto para a experiência de adicionar à tela inicial e melhorar a taxa de cliques.
Caixa de adicionar à tela inicial


Se um site cumpre os critérios do adicionar à tela inicial, o Chrome aciona um evento beforeinstallprompt e não exibe mais o banner de adicionar à tela inicial automaticamente. Em vez disso, quando o evento é acionado, os desenvolvedores podem salvá-lo e adicionar um botão ou outro elemento de IU ao aplicativo para indicar que ele pode ser instalado. Quando o usuário clica no botão de instalar, os desenvolvedores podem chamar prompt() no evento beforeinstallprompt salvo para apresentar a nova caixa modal de adicionar à tela inicial. Apesar de o evento beforeinstallprompt poder ser disparado sem um gesto do usuário, é preciso haver um para chamar prompt().


let installPromptEvent;

window.addEventListener('beforeinstallprompt', (event) => {
  // Prevent Chrome <= 67 from automatically showing the prompt
  event.preventDefault();
  // Stash the event so it can be triggered later.
  installPromptEvent = event;
  // Update UI notify the user they can add to home screen
  document.querySelector('#install-button').disabled = false;
});

Como solução temporária para dar aos desenvolvedores tempo para gerenciar beforeinstallpromptevent e adicionar um botão de instalação para o seu aplicativo, o Chrome vai exibir uma minibarra de informações na primeira vez em que o usuário acessar um site que cumpra os critérios do adicionar à tela inicial. Quando descartada, a minibarra de informações não será exibida de novo até que se passe tempo suficiente (atualmente, 3 meses).
Minibarra de informações do adicionar à tela inicial


Leia Mudanças no comportamento do adicionar à tela inicial para ver todos os detalhes, exemplos de código e capturas de tela dos novos elementos de IU.

Payment Handler API

A Payment Request API trouxe para a web uma maneira mais simples e rápida e finalizar compras on-line com uma combinação de IU nativa de navegador totalmente integrada e um formulário de pagamento e endereços de envio preferidos do usuário.

A Payment Handler API recém-lançada amplia as possibilidades do Payment Request, permitindo que aplicativos de pagamento web ofereçam pagamentos diretamente na experiência do Payment Request.


const request = new PaymentRequest([{
  // Your custom payment method identifier comes here
  supportedMethods: 'https://bobpay.xyz/pay'
}], {
  total: {
    label: 'total',
    amount: { value: '10', currency: 'USD' }
  }
});

Fazendo um pagamento pela Payment Request API. "Pay with BobPay" é um método de pagamento exclusivo desenvolvido com a Payment Handler API.

Protegendo os usuários de destinos indesejados

Nesta versão do Chrome, estamos mudando alguns comportamentos da interface do usuário para melhorar a experiência.

Gesto do usuário necessário para redirecionar em iframes de várias origens

A menos que proibido pelo atributo sandbox, o conteúdo embutido em um iframe pode, de forma geral, redirecionar o contexto de navegação geral para um site diferente. Esse recurso é usado por muitos tipos de site, incluindo provedores de acesso único (SSO, ou single-sign-on) e processadores de pagamento. Infelizmente, esse comportamento também é uma oportunidade comum de abuso, em que se redirecionam usuários a destinos indesejados sem seu consentimento ou conhecimento.

A partir do Chrome 68, o conteúdo embutido em um iframe exige um gesto do usuário para redirecionar o contexto de navegação geral para outro destino. De forma parecida com o bloqueio de pop-ups, quando essa proteção é acionada, a IU do Chrome dá aos usuários a opção de permitir o redirecionamento ou não.

Temos uma demonstração que ilustra esse comportamento. Esta demonstração mostra o comportamento antigo, presente até o Chrome 67. O novo comportamento funciona no Chrome 68.

Bloqueio de navegações em guia oculta

Um evento de guia oculta acontece quando uma página abre um pop-up para um destino e redireciona a página de chegada para conteúdo de terceiro. Normalmente, esse comportamento é usado para enviar o usuário ao destino correto e, ao mesmo tempo, criar outra guia com um destino não solicitado. Como nos pop-ups, o Chrome vai impedir essas navegações indesejadas e vai passar a exibir a IU nativa ao usuário para que ele possa escolher se quer ser redirecionado para o novo site.

A Page Lifecycle API

O ciclo de vida do aplicativo é uma forma essencial de gerenciar recursos para os sistemas operacionais modernos. No Android, no iOS e recentemente no Windows, os aplicativos podem ser iniciados e parados a qualquer momento pela plataforma. Com isso, essas plataformas conseguem simplificar e realocar os recursos da forma mais benéfica para o usuário.

Historicamente, na web não existe nada parecido, e os aplicativos podem ficar ativos para sempre. Com uma grande quantidade de aplicativos web (e guias) em execução, recursos essenciais, como memória, CPU, bateria e rede, podem ser consumidos em excesso, provocando uma experiência ruim para o usuário.

No Chrome 68, os desenvolvedores poderão detectar e reagir à suspensão da CPU para guias em segundo plano iniciada pelo sistema usando os novos eventos freeze e resume. Caso uma página travada precise ser descartada para conservar memória, a nova propriedade document.wasDiscarded permite aos desenvolvedores restaurar o estado da visualização (salvo no evento freeze) quando o usuário voltar a dar o foco à guia, e a página é recarregada. Os desenvolvedores que quiserem testar esses eventos nos aplicativos podem acessar chrome://discards para simular o congelamento, a retomada e o descarte de páginas.

Se quiser saber mais sobre a Page Lifecycle API, consulte a especificação ou o explicador no GitHub.

Outros recursos desta versão

CSS

Aceitar dois valores na abreviação de fluxo excessivo

A abreviação de overflow vai aceitar dois valores, permitindo atribuir os fluxos excessivos horizontais e verticais a diferentes valores. Se forem especificados dois valores, o primeiro será overflow-x e o segundo, overflow-y. Alterando essa abreviação, os desenvolvedores conseguirão especificar uma única declaração em vez de precisar de duas como anteriormente.

Valores de posição do CSS com três partes

As propriedades object-position e perspective-origin não aceitarão mais valores tripartidos, como "top right 20%". Isso também se aplica a posições em formas e gradientes básicos. Agora os valores de posição válidos sempre terão 1, 2 ou 4 partes. A suspensão dos valores de 3 partes aconteceu no Chrome 66.

Suporte a "x" como unidade de resolução

A especificação Módulo de unidades e valores CSS nível 4 estabelece uma nova unidade de resolução chamada "ponto por pixel" para oferecer suporte a telas de alta resolução. Essa mudança adiciona 'x' como sinônimo da abreviação atual, 'dppx'.

Valores CSS "grab" e "grabbing" sem prefixo para a propriedade "cursor"

Os valores CSS "grab" e "grabbing" alteram o cursor do mouse para "mão aberta" ou "mão fechada", símbolos comumente usados para indicar que é possível segurar algo ou que algo está sendo segurado no momento. As versões prefixadas dessas propriedades são suportadas desde o Chrome 1. Com essa mudança, o Chrome passa a suportar as versões padrão não prefixadas desses valores.

Gamepad

Data e hora de alta resolução para gamepad

Gamepad.timestamp agora usa DOMHighResTimeStamp, um horário monotônico de alta resolução com resolução em microssegundos. Os carimbos de data e hora são medidos como compensação da propriedade PerformanceTiming.navigationStart.

Elementos personalizados

Novo customElements.upgrade()

Essa função invoca construtores de elemento personalizado para elementos personalizados cujos construtores ainda não foram chamados explicitamente. Se um elemento personalizado é criado com o configurador innerHTML e seu nó superior não está conectado a um documento, o construtor do elemento personalizado não é chamado até estar conectado. Esse método permite explicitamente que os desenvolvedores controlem por completo o momento das chamadas do construtor de elemento personalizado, independentemente de estar conectado ou não.

Entrada

Bloqueio de teclado

Em tela cheia, esta API permite aos aplicativos receber comandos normalmente gerenciados pelo sistema ou pelo navegador, como Cmd-Tab/Alt-Tab ou Esc. Os usuários podem desativar o bloqueio de teclado (e a tela cheia) segurando a tecla Esc por dois segundos.

Tornar PointerEvent.fromElement e PointerEvent.toElement nulos

Para aumentar a consistência com outros navegadores, PointerEvents dos campos fromElement e toElement não seguem a especificação Eventos de ponteiro nível 2, e fazem isso sempre comunicando nulo.
Em um MouseEvent (a partir do qual um PointerEvent herda esses campos), fromElement e toElement não são padronizados e foram inconsistentes entre os navegadores por muitos anos. Além disso, já existem alternativas consistentes e padronizadas: target e relatedTarget.

Ajuste de toque unificado

O ajuste de toque muda o TouchEvent e o PointerEvent correspondente de destino para um destino melhor dentro da área de toque. As coordenadas de TouchEvent não serão alteradas.

Tratar pressionamento longo como gesto

Agora o pressionamento longo é considerado um gesto porque indica interação do usuário com a página. Com isso, um aplicativo web consegue chamar APIs restritas, como navigator.vibrate(), com o pressionamento longo para se adequar ao comportamento nativo.

Mídia

WebAudio: adicionar taxa de automação selecionável para AudioParams

O atributo AudioParam.automationRate
permite ao usuário selecionar se AudioParam é "a-rate" ou "k-rate". A maioria dos atributos de AudioParam permite alterar a taxa, como mencionado na especificação.
Por exemplo, BiquadFilterNode com automação "a-rate" padrão é muito pesado para processar devido à relação complexa entre os parâmetros e os coeficientes de filtro. Se essa automação rápida não for necessária (o caso mais comum), os parâmetros podem ser definidos como "k-rate".

ServiceWorker

Melhorar o gerenciamento de cache para scripts de service worker

O cache HTTP será ignorado ao solicitar atualizações ao service worker. As solicitações de importScripts continuarão passando pelo cache HTTP. Mas esse é só o padrão. Uma nova opção de registro, ServiceWorkerRegistration.updateViaCache, está disponível e oferece controle sobre esse comportamento.
Antes, as solicitações HTTP que verificavam se havia atualizações para o service worker eram atendidas pelo cache HTTP por padrão. Se um cabeçalho Cache-Control for acidentalmente aplicado a um service worker, as atualizações do service worker poderão ser adiadas, e se o service worker continha informações de versão dos outros ativos dos seus sites, essas atualizações também seriam adiadas.

Recursos removidos e melhorias de interoperabilidade

Às vezes, o Chrome suspende, remove ou altera recursos para melhorar a interoperabilidade com outros navegadores. Esta versão do Chrome vem com algumas mudanças desse tipo, que estão listadas a seguir.

Suspensão e remoção dos valores negativos para o brilho no filtro

Para cumprir a especificação, a função brightness() do filtro não aceita mais valores negativos.

Remoção de document.createTouch

O método document.createTouch() será sendo removido porque o construtor Touch() já é compatível desde o Chrome 48.

Remoção de Document.selectedStylesheetSet e Document.preferredStylesheetSet

Os atributos Document.selectedStylesheetSet e Document.preferredStylesheetSet foram removidos porque não são padronizados e só são implementados pelo Chrome e pelo WebKit. As versões padrão desses atributos foram removidas da especificação em 2016.

WEBGL_compressed_texture_atc

Antigamente, o Chrome fornecia os formatos AMD_compressed_ATC_texture. O suporte a hardware foi reduzido aos poucos a quase zero, por isso a extensão foi rejeitada pelo WebGL Working Group. Esse suporte foi removido.