Material-ui: Ripple permanece se multiclicked rápido

Qual navegador você está usando? Não consigo reproduzi-lo com o Chrome 59.

Incapaz de reproduzir em:

• Chrome 59.0.3071.115
• Firefox 54.0.1
• Edge 38.14393.1066.0
• IE 11.1358.14393.0

@oliviertassinari @kgregory Estou no Windows 10, Firefox 54.0.1.
Estou usando o touchpad do meu laptop para fazer isso em uma velocidade mais rápida com os dois dedos ... Acho que é a diferença porque com um dedo não consigo fazer isso. Não é um bug urgente, mas pode acontecer.

Também não consegui reproduzir (Windows 10, Firefox 54.0.1), mas no Chrome e com um botão direito (secundário) do mouse ele se comporta assim.

@NonameSLdev Estou em torno de 9 cliques por segundo e não consigo reproduzi-lo nessa versão do Firefox.

@Dattaya você está clicando repetidamente com o botão direito do mouse para reproduzir isso no Chrome?

Nevermind @Dattaya , eu reproduzi no Chrome clicando

Estou me perguntando se devemos ter uma ondulação com um clique direito do mouse? Eu diria que não. Então, talvez a solução certa seja desativá-los.

@oliviertassinari boa ideia, mas provavelmente haverá alguma outra combinação de interações do usuário dignas de ondulação que levam a esse comportamento. Você viu algo nos padrões sobre ondulações de tinta em cliques com o botão direito (acho que não há nada lá)? No Chrome, não há ondulações na barra de favoritos quando um favorito é clicado com o botão direito. Talvez isso seja evidência suficiente 😄

Observei isso por um tempo e não tenho certeza de por que essas ondulações estão sendo retidas no estado do TouchRipple (matriz de ondulação).

Em 9cps eu achei algo interessante: No firefox as ondulações não saem, no cromo elas saem muito lentamente. MAS, a cada clique no firefox, um botão que já tem ondulações que não deixaram outra ondulação aparece e depois sai e leva uma ondulação com ele. Comportamento estranho, de fato

O problema pode ter sido corrigido por # 7575. Eu diria 50/50 porque não consegui reproduzir

Acabei de puxar e reinstalar todas as dependências, ainda capazes de reproduzir clicando nos botões esquerdo e direito do mouse simultaneamente em um ritmo semi-rápido.

@kgregory Acho que é um problema no nível do ButtonBase nesse caso. Obrigado por experimentar.

Esse problema está me deixando louco, não importa o que eu tente, não consigo reproduzir. Eu adicionei a tag good first issue , se outra pessoa quiser resolver isso, ótimo, caso contrário, continuará sem solução.

@oliviertassinari Eu testei alguns. Só consigo reproduzi-lo com o touchpad do meu laptop, mesmo a 3 cps.

Oi pessoal, a princípio, bom trabalho.
Um pouco difícil de acompanhar o beta, mas está ficando mais incrível a cada dia.

@oliviertassinari usamos mui e temos alguns erros estranhos relacionados a esse problema, talvez isso ajude a corrigir isso: Em um Mac, usando o cromo você não pode reproduzir este problema e tudo funciona bem. Em uma máquina Linux, com cromo, os botões ondulados ficam cada vez mais escuros quando você clica em algo a 3 cps. Clicar rapidamente não reproduz isso. Notável é que girar o fastclick https://github.com/ftlabs/fastclick , que usamos, vai consertar isso, e os botões vão lidar com os eventos direito. Pressionar os botões na página mui-doc também não tem esse efeito, pois presumo que não haja bibliotecas com efeitos colaterais no material-ui. Talvez ajude a reproduzir ou delimitar esse problema.

Estou trabalhando em um aplicativo cordova iOS (com FastClick para evitar atrasos de 300ms) usando material-ui @ next (1.0 v23) e estou obtendo o mesmo comportamento. A remoção do FastClick parece consertar o acúmulo de ondulações de toque, mas resulta em uma UX pobre devido ao atraso de 300 ms.

@oliviertassinari Percebi que você tem um aplicativo chamado SplitMe que usa material-ui @ next + cordova, você conhece uma maneira de evitar esse bug de ondulação de toque quando usado em conjunto com o FastClick? Ou SplitMe também tem o atraso de 300ms?

PS antes, eu estava usando [email protected] com FastClick e não tinha problemas de propagação de toque

Ou SplitMe também tem o atraso de 300ms?

@ssalka Você pode notar o atraso na documentação? É um problema específico de Cordova? Faz muito tempo que não trabalho muito no SplitMe. Pelo que eu sei, o atraso pode ser removido com a meta da janela de visualização. A ser confirmado.

Acho que é um problema do Cordova (mais especificamente, o iOS UIWebView). Na verdade, não consegui encontrar SplitMe na app store e, infelizmente, não tenho como verificar se a documentação carrega no meu projeto, pois o CORS está desabilitado e links HTML para outros domínios abrem no Safari (tentei um iframe, sem sorte) . Tudo o que posso dizer com certeza é que as ondulações de toque funcionam bem na v0.x e aumentam na v1.

Em geral, parece que todos os principais navegadores (até mesmo o Safari para iOS!) Implementaram uma correção usando a metatag de viewport, como você disse, mas ainda está presente no UIWebView usado internamente pelo Cordova. Eu não contaria o Cordova como um navegador / plataforma importante, então vou entender se isso não for considerado um problema prioritário.

Obrigado pela resposta rápida!

@ssalka Você já tentou https://github.com/apache/cordova-plugin-wkwebview-engine?

Eu confirmo que é muito melhor. Estou usando este plugin no SplitMe .

@NonameSLdev Você ainda pode reproduzir o problema? A questão não avançou muito em um ano. Acho que será seguro fechá-lo.

Sim, o mesmo comportamento - a ondulação permanece e a cada pairar parte dela se perde por si mesma.

Não é realmente um problema importante, mas existe.

ATUALIZAÇÃO : Espere. Acabei de ter uma ideia. E se se tratar de mais movimentos do mouse (também conhecidos como cliques) do que para cima? Porque usando o trackpad, isso pode acontecer quando estou usando dois dedos para pressionar repetidamente.

Acabei de testar esta teoria e parece ser verdade: ao fazer multiclicking como eu faço para criar a ondulação, obtive 21 eventos de mouse para baixo e apenas 11 eventos de mouse para cima. Acho que esse é o motivo. #TookUsLongEnough

@stavlocker @oliviertassinari Eu tenho encontrado esse problema há algum tempo. No meu caso, finalmente consegui rastrear '-webkit-app-region': 'no-drag' removendo a propriedade, resolvi completamente o problema para mim. Suspeito que isso seja semelhante ao problema mencionado # 11696

Apenas para sua informação, estou usando openfin no Chrome 61

@gtsafas Talvez isso pudesse consertar, mas como eu disse no meu comentário (acima do seu) é porque há mais movimentos do mouse para baixo do que para cima. Sem olhar para o código, posso dizer que a ondulação é criada com o mouse para baixo e removida com o mouse para cima - mas esse mouse para cima nunca chegou porque há mais baixos do que altos. Sua correção é boa, mas só funcionaria em navegadores webkit.

Duas soluções a meu ver:

• Sugiro que coloquemos um temporizador nas ondulações. Se não for removido após 5 segundos, remova-o automaticamente. No lado da UX, deve-se considerar que isso pode confundir os usuários que pressionam longamente e veem a ondulação liberada, talvez fazendo-os pensar que pressionaram o botão liberando o clique (quando não o liberaram).
• Basta criar a ondulação com o mouse para cima ao invés do mouse para baixo. Isso obviamente pareceria diferente e se um usuário segurasse um botão, ele não veria uma ondulação, mas corrige isso.

@stavlocker sim, eu não estava propondo isso como uma solução. Mas eu estava dizendo que o outro problema que causa isso é arrastar imagens. Para mim não eram especificamente imagens, mas algo que interage com o arrastar. Algo estava impedindo o mouseup de ocorrer. Pelo menos no meu caso não foi relacionado a usuários com velocidades de clique diferentes, aconteceu para todos enquanto aquele css estava lá.

Podemos colocar um cronômetro ou mouse, mas eles estão apenas escondendo o problema. Acho que precisamos saber por que o mouse up não está disparando antes de corrigi-lo.

Isso acontece com você em todos os sites do material-ui?

@gtsafas Isso é interessante. Mas não é um bug do MUI que o mouse não está disparando. No meu caso, é porque, com meu trackpad, posso usar dois dedos para clicar. Meus pensamentos são que porque eu uso dois dedos que podem acionar outro mouse para baixo quando já houver um para baixo, às vezes eu levanto meu outro dedo enquanto o segundo é pressionado que o trackpad não detecta como um mouse para cima porque há algo pressionado. Isso causa mais baixas do que altas, portanto, a ondulação permanece.

@stavlocker ok então isso é diferente. Ao tentar depurar isso (antes de perceber que era -webkit-app-region), adicionei o registro ao redor do mouse para cima / para baixo e também observei mais baixas do que altas.

Então, se você conectar um mouse normal, ele funcionará bem?

@gtsafas você pode reproduzir o comportamento com um mouse clicando simultaneamente nos botões esquerdo e direito.

nós também tivemos esse problema. você provavelmente está evitando outros eventos de mouse ... verifique seu código por algo como:

document.addEventListener("mousedown", myScript); // should be document.addEventListener("mousedown", myScript, false);
document.addEventListener("mouseup", myScript); // should be document.addEventListener("mouseup", myScript, false);

//jquery example: 
        // (...)
        documentElement.on({
            'mouseup': (e) => {
                e.preventDefault(); // WRONG! cut this off
                isDrag = false
            },
        // (...)
        });

@ejnu Devemos prevenir a invariante padrão. Algo pode estar errado.

@kgregory @oliviertassinari
Não tenho certeza se isso está certo, mas aqui está o que descobri após alguns testes:
De alguma forma, isso acontece quando um clique interage com o menu de contexto de uma maneira estranha. Eu testei isso ao não conseguir que a ondulação persistisse com: onContextMenu={e => {e.preventDefault()}} no ButtonBase. Não parece que você pode detectar quando um clique acontece no menu de contexto, mas acho que consegui corrigir isso interrompendo a ondulação no evento do menu de contexto: # 13740

   handleTouchMove = createRippleHandler(this, 'TouchMove', 'stop');

+  handleContextMenu = createRippleHandler(this, 'ContextMenu', 'stop');

   handleBlur = createRippleHandler(this, 'Blur', 'stop', () => {
    clearTimeout(this.focusVisibleTimeout);
    if (this.state.focusVisible) {


        onTouchEnd={this.handleTouchEnd}
        onTouchMove={this.handleTouchMove}
        onTouchStart={this.handleTouchStart}
+       onContextMenu={this.handleContextMenu}
        ref={buttonRef}
        tabIndex={disabled ? '-1' : tabIndex}
        {...buttonProps}

Alguém pode confirmar?

@ 0maxxam0 financiou este problema com $ 40. Veja em IssueHunt

Deve ser resolvido com # 13740. Se você conseguir reproduzir o problema com a versão mais recente, informe-nos!

@oliviertassinari @kgregory ainda posso reproduzir, como já disse no # 13740. Este PR corrige apenas o spam do menu de contexto, mas não o spam do trackpad. Este comentário descreve o problema que estou sofrendo e oferece duas soluções.

Maneiras de reproduzir:

1. Vá para as demonstrações do componente do
2. Use o trackpad para clicar no botão várias vezes

Estou usando um Lenovo Yoga 700 com Windows 10, pode reproduzir no Chrome 71, Firefox 64 (Quantum), Edge 42.

Tenho certeza de que isso pode ser reproduzido em diferentes computadores, pois o problema é que o trackpad registra vários dedos e às vezes não registra tanto para cima quanto para baixo do mouse, como concluí em meus testes anteriores .

Estou vendo o sombreamento de ondulação cumulativo do botão no meu fone de ouvido, reagir mui app em um iPad. no Android e na Web não há problema. Cada vez que clico no botão fica mais escuro (ou mais claro) até saturar.

Também posso confirmar esse problema no Safari / iOS - nem leva um toque rápido, a sobreposição de escuro / claro simplesmente nunca desaparece depois de tocar nele.

@oliviertassinari @kgregory ainda posso reproduzir, como já disse no # 13740. Este PR corrige apenas o spam do menu de contexto, mas não o spam do trackpad. Este comentário descreve o problema que estou sofrendo e oferece duas soluções.

Maneiras de reproduzir:

1. Go to the [button component demos](https://material-ui.com/demos/buttons/)

2. Use your trackpad to click the button a bunch of times

Estou usando um Lenovo Yoga 700 com Windows 10, pode reproduzir no Chrome 71, Firefox 64 (Quantum), Edge 42.

Tenho certeza de que isso pode ser reproduzido em diferentes computadores, pois o problema é que o trackpad registra vários dedos e às vezes não registra tanto para cima quanto para baixo do mouse, como concluí em meus testes anteriores .

Se o problema for que há mais eventos mousedown disparados do que mouseup, devemos verificar se há um número correspondente de mouseup fora desse elemento. Um truque para esse tipo de coisa é adicionar um manipulador de mouse para cima (que se auto-removeria) ao elemento DOM raiz com o mouse pressionado, então o mouse para cima sempre disparará, não importa onde o mouse foi capturado. Suspeito que sempre haja algum evento que é acionado para acionar a limpeza, mas pode não ser no elemento de origem.

@CaptainN Em qual iOS / Safari você está reproduzindo. Não consigo recriar no iOS 12.1.2

iOS 11.3.1 - vejo principalmente nos componentes IconButton, mas também no Fab.

Parece que deve:

1. Anime o círculo a partir do ponto de contato.
2. Fade out (alfa) durante a animação.
3. Presumo que seja removido e limpo após a conclusão da animação.

As etapas 2 e 3 para mim não estão acontecendo no meu iPad (11.3.1), em um iPhone mais antigo (11.4.1) ou no iPhone 8 (12.1.2).

Vou ver se consigo me aprofundar no código em algum momento, mas não posso fazer nenhuma promessa sobre o tempo.

@CaptainN Isso está nas demos do docs ou no seu próprio código? Não consigo reproduzi-lo com os documentos em um iPhone 10 com iOS 12.1 ou um iPad mais antigo com 12.1.3, então estou me perguntando se há fatores de confusão em jogo?

Não estou dizendo que não é um bug, mas pode haver mais etapas necessárias para reproduzi-lo.

Está no meu próprio aplicativo, que é um aplicativo de tamanho médio construído com Meteor, React e Material-UI. Na verdade, ele se tornará público em breve, então posso compartilhar um link.

Eu irei procurar a causa no código em algum ponto e, se não conseguir encontrar, tentarei produzir uma redução.

Também estou usando SSR - recebo alguns avisos sobre atributos de estilo incompatíveis, geralmente o servidor ou cliente não concorda com o prefixo -webkit- - isso poderia ter algo a ver com isso? Na verdade, não tenho certeza de como o material-ui aplica os prefixos (autoprefixer) - existem documentos sobre isso?

Isso pode ajudar:
https://material-ui.com/getting-started/supported-platforms/#css -prefixing

Também estou enfrentando esse problema em meu próprio ambiente usando Meteor, React e Material-UI e apenas no iOS. Consegui usar o emulador de dispositivo do Chrome e apenas obter esse bug para disparar ao emular dispositivos iOS e não dispositivos Android.
Não consigo replicar isso com as caixas de proteção de demonstração ainda, mas pode se originar do componente ButtonBase porque estou vendo o problema com botões e guias.

Agora estou vendo isso até mesmo no Chrome no Windows com o modo móvel habilitado nas Ferramentas de Desenvolvimento. Neste aplicativo: https://www.pixstoriplus.com/

@CaptainN Vou dar uma olhada mais tarde. Apenas por uma questão de clareza, você pode postar suas etapas de reprodução. Qual Chrome você está usando?

Estava fazendo isso de forma bastante consistente antes, mas agora que estou tentando reproduzi-lo no Chrome, nada. Algo deve tê-lo colocado em algum tipo de estado de erro.

No iOS, você pode simplesmente carregar o aplicativo e ver o problema com bastante facilidade. Toque para frente e para trás entre os botões de página inicial e de pesquisa no painel de navegação inferior para obter o exemplo mais fácil. Ou toque em pesquisar, depois volte para casa e pressione casa algumas vezes.

Posso recriá-lo no iOS na navegação inferior.

Consegui obter um comportamento mais consistente se você recarregar a página depois de alternar do Chrome normal para o modo de dispositivo.

@ zuus-keith Se estiver relacionado ao simulador móvel da ferramenta chrome dev, não é algo que devamos corrigir. A menos que seja a mesma causa raiz?

@oliviertassinari Acredito que seja a mesma causa raiz. Inicialmente me deparei com isso em um dispositivo iOS real, mas acontece que o simulador móvel da ferramenta Chrome dev definido para visualizações 'iPhone' ou 'iPad' produz o mesmo comportamento.

Para adicionar, até agora o problema só foi relatado em 3 instâncias diferentes, mas todas usando a mesma pilha de tecnologia (ou seja, Meteor, React e MUI).

Isso acabou sendo devido a outro pacote Meteor muito comum chamado "fastclick" - que não era realmente necessário (se você usar as configurações corretas da janela de visualização) no Safari por anos. Se alguém encontrar esse problema, a solução é simplesmente remover "fastclick".

Existe alguém que é afetado por isso e não em um ambiente simulado? Ou posso fechar isso?

Isso foi corrigido para mim em ambientes não simulados (no iPad) removendo o pacote fastclick do meu aplicativo meteoro.

Fechando por enquanto, se alguém puder reproduzir nos avise.