Ripple stays if multiclicked fast

[NonameSLdev]

If someone clicks in about >9 clicks per second for a little while (1-2 seconds) the ripples don't leave the button and it stays with the color. Small demonstration:

You're welcome to try it yourself: https://material-ui.com/demos/buttons/#text-buttons

EDIT: This comment describes the issue - there are more mouse downs than ups and the ripple isn't released.

[oliviertassinari]

What browser are you using? I can't reproduce it with Chrome 59.

[kgregory]

Unable to reproduce in:

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

[NonameSLdev]

@oliviertassinari @kgregory I'm on Windows 10, Firefox 54.0.1.
I'm using my touchpad on my laptop to do it in a faster speed with both fingers... I guess that's what's different because with one finger I can't manage to do it. It's not an urgent bug but it could happen.

[Dattaya]

I couldn't reproduce either (Windows 10, Firefox 54.0.1) but in Chrome and with a right (secondary) mouse button it does behave like that.

[kgregory]

@NonameSLdev I'm around 9 clicks per second and can't reproduce it in that version of Firefox.

@Dattaya are you repeatedly clicking with the right mouse button to reproduce this in Chrome?

[kgregory]

Nevermind @Dattaya, I reproduced in Chrome by semi-rapidly clicking left and right mouse button simultaneously about ten times.

[oliviertassinari]

I'm wondering should we have a ripple with a right mouse click? I would say no. So maybe the right fix is to disable them.

[kgregory]

@oliviertassinari good thought, but there will probably be some other combination of ripple-worthy user interactions that lead to this behavior. Have you seen anything in the standards about ink ripples on right-clicks (I'm guessing there's nothing there)? In Chrome, there are no ripples on the bookmark bar when a bookmark is right-clicked. Maybe this is enough evidence 😄

I've looked at this for a little while and I'm not exactly sure why these ripples are being stranded in the TouchRipple's state (ripple array).

[NonameSLdev]

At 9cps I found something interesting: On firefox the ripples don't leave, on chrome they leave extremely slowly. BUT, on each click on firefox on a button that already has ripples that didn't leave another ripple shows up then leaves and takes a ripple with it. Odd behaviour indeed

[oliviertassinari]

The issue might have been fixed by #7575. I would say 50/50 as I haven't been able to reproduce

[kgregory]

Just pulled and reinstalled all dependencies, still able to reproduce by clicking left and right mouse buttons simultaneously at a semi-rapid pace.

[oliviertassinari]

@kgregory I guess it's an issue at the ButtonBase level in that case. Thanks for trying it out.

[oliviertassinari]

This issue is driving me crazy, no matter what I try, I can't reproduce. I have added the good first issue tag, if someone else want to address it, great, otherwise, it will stay unresolved.

[stavlocker]

@oliviertassinari I tested it around a few. I can only reproduce it with my laptop's touchpad, even at 3cps.

[AndreasZeissner]

Hi guys, at first, nice work.
A bit rough to keep up with beta, but it is getting more awesome on a daily basis.

@oliviertassinari we use mui an have some strange errors concerning this issue, maybe this helps to fix this: On a Mac, using chrome you cannot reproduce this issue and everything works just fine. On a Linux machine, with chrome, rippling buttons get darker and darker when you click it at something at 3cps. Clicking it fast does not reproduce this. Remarkable is, that turning of fastclick https://github.com/ftlabs/fastclick, we use, will fix this, and buttons will handle the events right. Pressing the buttons on the mui-doc page also does not have this effect, as i assume, there are no libraries having any side effects on material-ui. Maybe it helps to reproduce or delimit this issue.

[ssalka]

I'm working on a cordova iOS app (with FastClick to avoid 300ms delay) using material-ui@next (1.0 v23) and I'm getting the same behavior. Removing FastClick seems to fix the touch ripples building up, but results in poor UX due to the 300ms delay.

@oliviertassinari I noticed you have an app called SplitMe that's using material-ui@next + cordova, do you know of a way to avoid this touch ripple bug when used in tandem with FastClick? Or does SplitMe also have the 300ms delay?

P.S. before I had been using [email protected] with FastClick and had no touch ripple issues

[oliviertassinari]

Or does SplitMe also have the 300ms delay?

@ssalka Can you notice the delay in the documentation? Is it a Cordova specific issue? I haven't been doing much work on SplitMe for a long time. As far as I know, the delay can be removed with the viewport meta. To be confirmed.

[ssalka]

I think it is a Cordova issue (more specifically, the iOS UIWebView). I actually couldn't find SplitMe in the app store, and unfortunately I have no way to check whether the documentation loads in my project, as CORS is disabled and HTML links to other domains open up in Safari (tried an iframe, no luck). All I can say for certain is that the touch ripples work fine on v0.x, and build up in v1.

In general it looks like all the major browsers (even Safari for iOS!) have implemented a fix using the viewport meta tag, like you said, but it is still present in the UIWebView used internally by Cordova. I wouldn't count Cordova as a major browser/platform though, so I'll understand if this is not counted as a priority issue.

Thanks for the quick response!

[CaptainN]

iOS 11.3.1 - mostly I see it on IconButton components, but also on Fab.

[CaptainN]

It looks like it's supposed to:

1. Animate the circle from touch point out.
2. Fade out (alpha) while animating.
3. I assume get removed and cleaned up after the animation is complete.

Steps 2 and 3 for me are not happening on my iPad (11.3.1) an older iPhone (11.4.1) or iPhone 8 (12.1.2).

I'll see if I can dig into the code at some point, but can't make any promises about timing.

[mbrookes]

@CaptainN Is this in the docs demos, or your own code? I can't reproduce it with the docs on an iPhone 10 with iOS 12.1, or an older iPad with 12.1.3, so I'm wondering if there are confounding factors at play?

Not saying it isn't a bug, but there may be more steps required to reproduce it.

[CaptainN]

It's in my own app, which is a medium sized app built with Meteor, React and Material-UI. It'll actually be public soon, so I can share a link.

I'll both look for the cause in code at some point, and if I can't find it, try to produce a reduction.

[CaptainN]

I'm also using SSR - I do get some warnings about mismatched style attributes, usually the server or client doesn't agree on the -webkit- prefix - could that have something do with it? I'm actually not really sure how material-ui applies prefixes (autoprefixer) - are there docs on that?

[mbrookes]

This might help:
https://material-ui.com/getting-started/supported-platforms/#css-prefixing

[zuus-keith]

I am also experiencing this issue in my own environment using Meteor, React and Material-UI and only on iOS. I've been able to use Chrome's device emulator and only to get this bug to trigger when emulating iOS devices and and not Android devices.
I can't seem to replicate this with the demo sandboxes yet but it might stem from the ButtonBase component because I seeing the issue with buttons and tabs.

[CaptainN]

I'm now seeing this even in Chrome on Windows with mobile mode enabled in Dev Tools. On this app: https://www.pixstoriplus.com/

[joshwooding]

@CaptainN I’ll have a look later. Just for clarity sake can you post your reproduction steps. What Chrome are you using?

[CaptainN]

It was doing it quite consistently before, but now that I'm trying to reproduce it in Chrome, nothing. Something must have put it into an error state of some kind.

On iOS, you can just load that app up and see the problem pretty easily. Tap back and forth between home and search buttons in the bottom nav for the easiest example. Or tap search, then back to home, and press home a few times.

[joshwooding]

I can recreate it on iOS on the bottom navigation.

[zuus-keith]

I was able to get more consistent behaviour if you reload the page after switching from regular Chrome to device mode.

[oliviertassinari]

@zuus-keith If it's related to the chrome dev tool mobile simulator, it's not something we should particularly fix. Unless it's the same root cause?

[zuus-keith]

@oliviertassinari I believe it is the same root cause. I initially came across it on an actual iOS device, it so happens that chrome dev tool mobile simulator set to 'iPhone' or 'iPad' views produce the same behaviour.

To add on, so far the issue has only been reported on 3 different instances but all using the same tech stack (i.e. Meteor, React and MUI).

[CaptainN]

This turned out to be due to another very common Meteor package called "fastclick" - which hasn't really been necessary (if you use the right viewport settings) in Safari for years. If anyone happens across this issue, the solution is to simply remove "fastclick".

[joshwooding]

Is there anyone who is affected by this and not in a simulated environment? Or is it okay to close this?

[CaptainN]

This was fixed for me in non-simulated environments (on iPad) by removing fastclick package from my meteor app.

[joshwooding]

Closing for now, if anyone can reproduce let us know.

[RohanGhalib]

you can recreate by clicking on a button, and then dragging outside the range of button while holding.
i was able to do this in settings page of chromium on ubuntu