Vuetify: [Bug Report] VStepper & VTabs transitions between steps are sometimes broken.

[MatthewAry]

Versions and Environment

Vuetify: 1.5.13+ & 2.0.0-beta.9
Vue: 2.6.10
Browsers: Google Chrome
OS: Windows, Mac OSX

Steps to reproduce

Go to Codepen.
Click the continue button and observe transition.
Click the continue button and observe the transition again.

Expected Behavior

The previous step should exit left while the next step should enter right using a sliding transition.

Actual Behavior

The previous step exits left while the next step appears. This issue can be seen on the first step, however the second step seems to not exhibit the transition issue.

Reproduction Link

https://codepen.io/MatthewAry/pen/rbbzJz

Other comments

I have been able to reproduce this on MacOS and Windows on Google Chrome 74. Assuming that none of my Google Chrome plugins are the cause, this issue should be reproducible.

Video:
https://drive.google.com/open?id=1Mr8vgQXi-kWx38vbhAOzeunIMBZLcwQM

EDIT:
This same behavior has been observed with vtabs

EDIT: Similar issues are observable on Vuetify 2 Beta: Video

[sean-kennedy]

We noticed this yesterday after my Chrome updated to 74. We tested on a computer running Chrome 73 where it worked as expected then after only updating Chrome to 74 it started the same behaviour as above.

[CesarGomezTissini]

We noticed this sometime ago too but never was able to reproduce it outside our project. We took decision, in first instance, to avoid v-input autofocuses when go to next step. At least in Safari works. Then it was solved putting a ref in that input inside of setTimeout.

[MatthewAry]

I have observed this behavior with v-tabs as well.

[CesarGomezTissini]

I have observed this behavior with v-tabs as well.

I noticed now this issue is related to window itself.

[CesarGomezTissini]

We noticed now this issue happened much more in Safari / Chrome in iOS. When I say "much more", I mean "easier to reproduce".

[MatthewAry]

Likely related to #7088

[MatthewAry]

I believe this might be a bug that was introduced in one of the recent releases. I am not observing this behavior on a project of mine (which I don't update frequently) which is using Vuetify 1.5.8.

[MatthewAry]

Okay, I was wrong. This is likely an issue that was introduced with Google Chrome's most recent update. I have been trying to track down this regression by downgrading vuetify on my project until I see the issue disappear. I am still seeing it in 1.5.8.

[ligne13]

Same issue with v-window. Visible in the docs https://vuetifyjs.com/en/components/windows#windows

[tahnik]

I am having the same issue with bottom sheets and dialogs. For some reason I cannot see the issue in the Vue website but is affecting my app.

[MatthewAry]

Please do not close this issue because it's fixed in 2.0.
1.5 is going now in LTS and this should be a bug that will get fixed in a maintenance update.

[johnleider]

Please keep in mind that the current plan for LTS is critical bugs and security vulnerabilities. Any regular issues that are triaged will be selective based upon the most active/requested.

I've outlined the current LTS plans here https://next.vuetifyjs.com/getting-started/long-term-support

[MatthewAry]

So far: 8 thumbs up, 7 participants, #7216 #7244 #7088 (all closed).
This issue affects components that use v-window apparently.
Only visible on Google Chrome which has the lion share of the web browser market.
This issue is cosmetic but its a glaring one such that its been discussed in the discord bugs channel on several occasions.

I would say that this issue has relatively broad impact.

[CesarGomezTissini]

So far: 8 thumbs up, 7 participants, #7216 #7244 #7088 (all closed).
This issue affects components that use v-window apparently.
Only visible on Google Chrome which has the lion share of the web browser market.
This issue is cosmetic but its a glaring one such that its been discussed in the discord bugs channel on several occasions.

I would say that this issue has relatively broad impact.

I told this 2 months ago

[mmghv]

having the same issue.
can always reproduce it when changing pages then the issue will happen the first time the tab is changed (very annoying).

---

Vuetify: 1.5.16
Vue: 2.6.10
Browsers: Google Chrome 75
OS: Windows

[gow1979]

I have the same broken anmations with v-stepper.
I can verify that everything was fine before Chrome 74.
I tried to find out what exactly did change in the chrome update, but with no success.
Maybe it is in some way connected to "prefers-reduced-motion"
https://developers.google.com/web/updates/2019/03/prefers-reduced-motion
...but thats just a blind guess

[DRoet]

Workaround might be to add overflow: hidden to .v-window__container. the transition will still mess up every now and then but atleast the visible overflowing should be gone.

[Shuyinsama]

This issue does not seem to be entirely cosmetic.
What I notice in which I think this issue is related to a issue I have with v-tabs.

Whenever this happens I notice that the classes for the tab transition are stuck on the tab-item element. We have a table inside the content with a row that can be expanded. Sadly when expanding it works but gets cut off by the dynamically set height.

Making our footer buttons "disappear". So it's not entirely cosmetic and depending on the use case could impact the application itself.

Clicking around through the issues it seems this has been noted but I am unable to find a clear answer if this is fixed in 2.0? Even though I do agree that 1.5 should get a fix for this too

[MatthewAry]

I am now seeing this in Version 2 of Vuetify. Reproducible in the docs. Video for proof https://drive.google.com/open?id=1GOKF1EoVjoHxeUF7YUqo-RB9E979dF8G

[johnleider]

I have been unsuccessful in solving this so far, any help would be appreciated.

[hamutaro89]

.v-tabs .v-window__container{
  overflow: hidden !important;
  height: auto !important;
}

[chouhanyang]

FYI, the reason for the content to go out of boundary is because the transition's v-window__container--is-active class may be removed too early due to race conditions in VWindowItems.ts. It is not clear to me why the container window doesn't have "overflow: hidden" style in the first place. My guess is that vuetify doesn't want to add unnecessary CSS to the container.

It is important to know that the transition state may be cancelled early. For example, if you repeatedly switching two tabs really fast. In this case, I found no way to ensure any transition event l being fired accordingly after cancellation. Thus, the best solution is to remove active state at the point when cancel event being triggered.

Otherwise, this should be an easy fix in VWindow.sass.

[chouhanyang]

I think the change https://github.com/vuetifyjs/vuetify/pull/8205 also fixed this issue. By handling both enter and leave windows without async calls, I no longer seeing this issue.

[MatthewAry]

Vuetify v2.0.12 may have fixed this issue via #8205
All those who have been affected by this issue and have been watching, please update your vuetify package and message here if you can still observe this issue or if it has been resolved.

[mmghv]

I didn't notice it anymore for a while now, I was able to reproduce it every time but now I can't, I'm still using the same version of vuetify 1.5.16, but chrome has been updated.

maybe it was a chrome bug that was fixed in recent updates. not sure though.

[chouhanyang]

Since this bug is caused by a race condition that triggers a preemptive transition cancellation, your chance to reproduce this issue may vary depending on your environment. I would suggest the following way to test: repeatedly switching between 2~3 tabs quickly, and make sure you click next tab before previous transition ends. Trying this for few times.

I can still reproduce this issue on old v1.5.x official docs site https://v15.vuetifyjs.com/en/components/tabs with the same tricks.

[mmghv]

@chouhanyang Tried what you said, can't reproduce it on docs page or in my app.

Note before, I was able to ALWAYS reproduce it when changing route pages as I illustrated in my previous reply. But now I can't reproduce it at all, having the same exact vuetify version (1.5.16) in same app as before when I first noticed the bug. but chrome version updated from 75 to 76.

[chouhanyang]

Note before, I was able to ALWAYS reproduce it when changing route pages as I illustrated in my previous reply. But now I can't reproduce it at all, having the same exact vuetify version (1.5.16) in same app as before when I first noticed the bug. but chrome version updated from 75 to 76.

Yeah, that's why race condition bugs are very difficult to tame. Maybe I'm just unlucky keep seeing them. XD

@mmghv How about Firefox, Edge and/or Opera? :) I can still reproduce the issue on those browsers as well. And don't forget to remove the CSS workaround if you use it previously.

[mmghv]

How about Firefox, Edge and/or Opera? :) I can still reproduce the issue on those browsers as well. And don't forget to remove the CSS workaround if you use them previously.

I only have Firefox beside Chrome, and no, the issue doesn't appear on Firefox, and I think it didn't appear on Firefox before when I first noticed it on Chrome (although don't remember exactly)

[MatthewAry]

The race condition may still exist in v1.5 It would be nice if there could be a backport for the fix. However the question was if the issue appears fixed for v2

[johnleider]

This fix for this is quite involved and will not be backported. This is considered resolved as of the latest release of v2.

[CesarGomezTissini]

@johnleider, you practically force us to migrate our projects when it could lead months doing this, especially when one is huge. Please, at least provide us with a temporary solution or a workaround for this problem.

[RomuloDevelop]

@CesarGomezTissini I agree, i'm working on a legacy project with version 0.17 and the issue with steppers is present. I suppose i'm fuck :(