fix(material/tabs): remove delay on touch devices

[crisbeto]

Fixes that the tabs had a small delay on touch devices.

Fixes #31488.

[FrostKiwi]

Quick note for testing:

I made exactly the same modification in our code last week. (as an override in another SCSS class)
I found that it solved the delay in the Chrome Dev Mode Device emulation, but did not solve it on real hardware, specifically on:

• iOS 18.5 Safari, iPhone SE3
• iOS 18.5 Edge, iPhone SE3
• iPadOS 18.5 Safari, iPad 9th gen
• iPadOS 18.5 Edge, iPad 9th gen

On these devices touch-action: manipulation; had no effect and the 300ms delay stayed in place. (Also tried other touch-action: XXX in other places) That's why I didn't suggest it as a solution #31488 initially.

[github-actions]

Deployed dev-app for ea45c96 to: https://ng-dev-previews-comp--pr-angular-components-31489-dev-nuk8yb8g.web.app

Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt.

[crisbeto]

That sounds like there may be something more going on that is slowing the page down (e.g. heavy component being rendered out inside the tabs). I can actually only reproduce the delay on the Chrome device emulation, but not on an iPhone 13 with iOS 18.5, neither in the docs site or our local development app. It's also worth noting that Webkit removed the delay by default almost 10 years ago.

Do you notice any delay in these two demos?

1. This is our local app at head: https://ng-comp-devapp.web.app/tabs
2. This is our local app including the fix from this PR: https://ng-dev-previews-comp--pr-angular-components-31489-dev-nuk8yb8g.web.app/tabs

[FrostKiwi]

Tested on real hardware, recorded evidence. The issue is still there, see below.

may be something more going on that is slowing the page down (e.g. heavy component being rendered out inside the tabs)

That was my first thought, but it's not the case, happens on empty mat-tabs as well and in your official samples.

It's also worth noting that Webkit removed the delay by default almost 10 years ago.

I saw that history when trying to debug this. Something about mat-tabs is cursed, in a way that it triggers that 300ms delay anyway on iOS / iPadOS Safari / Edge, see the following evidence.

I recorded this on an iPad 9th gen, iPad OS 18.5, on Safari. I tested both branches the links you provided. I used the "No Animation" variants, to prevent animation messing with our results. I'm interested in the time from touch to the tab becoming visible / turning blue.

Timeline.1.mp4

Here I made it frame by frame.
Here I touch "Third". This kicks of a "touch in progress" animation, this increasing radius circle. This takes time. In this recording, ~15 frames. Looking at the VRR timestamps, it works to roughly out to ~300ms.
Frame 1 is the first frame that is visually different, after the touch is performed:

• Frame 1
• Frame 2
• Frame 3
• Frame 4
• Frame 5
• Frame 6
• Frame 7
• Frame 8
• Frame 9
• Frame 10
• Frame 11, 12, 13, 14, 15
• Frame 16

Chrome's device emulation does the same and there it is fixed by touch-action: manipulation. But not on iOS Safari, not on iPad Safari, there this animation touch thingy delays the event from processing.

I am not holding my finger on the tab, it's an instant tap and release. Safari enforces this delay.

In fact, the tab sliding animation doesn't even start until 300ms later, until the delay is over. This is the main reason for sluggish lag feeling. This doesn't happen on Andoird, neither on Firefox mobile, nor Chrome Android, in neither branches. But on iPad OS Safari, iOS Safari it does.

[crisbeto]

Do you see the same in this example that sets animationDuration="0"? https://material.angular.dev/components/tabs/examples#tab-group-animations Kicking off the animation is tied to change detection so it's possible that it takes some time for the change to be detected and propagated to the DOM.

[FrostKiwi]

Do you see the same in this example that sets animationDuration="0"? https://material.angular.dev/components/tabs/examples#tab-group-animations Kicking off the animation is tied to change detection so it's possible that it takes some time for the change to be detected and propagated to the DOM.

Yes, that is the exact example that I tested in the above recording.