Vuetify: [Bug Report] Dialog is closed by clicking on Snackbar

[jloewe]

Versions and Environment

Vuetify: 1.5.14
Vue: 2.6.10
Browsers: Chrome 74.0.3729.108
OS: Windows 10

Steps to reproduce

1. Open Dialog
2. Close Snackbar

Expected Behavior

Only Snackbar closes

Actual Behavior

Dialog and Snackbar close

Reproduction Link

https://codepen.io/jloewe/pen/dEjGMw (v1.5.14)
https://codepen.io/jloewe/pen/ZNjQrr (v2.0.0-alpha.20)

[KaelWD]

Workaround is to add persistent to the dialog.

[jacekkarczmarczyk]

It happens also in normal (not fullscreen) dialogs https://codepen.io/anon/pen/zgGLgK which makes the workaround not so great in this case

[payammeyer]

Any update on this? The workaround (persistent prop) doesn't work for me either.

[185driver]

Workaround is to add persistent to the dialog.

I'm not finding this to be true (#9378). How are you getting this to work?

I believe this bug is a regression, since the problem doesn't exist in my v1.3 project.

[payammeyer]

@185driver right, that doesn’t work for me either, very frustrating.

[MajesticPotatoe]

@185driver there's another issue at play as well. Conflict between hide-overlay and persistent #8697
With fullscreen prop hide-overlay is assumed thus persistent wont work. on your codepen dialog, if you remove hide-overlay it works

[payammeyer]

@MajesticPotatoe I just tried removing hide-overlay too and it still doesn't work, here are my props:

<v-dialog
        v-model="dialog"
        fullscreen
        persistent
        transition="dialog-bottom-transition"
>

[185driver]

@MajesticPotatoe Thanks. Indeed, that was noted in the issue I posted. I wasn't aware that fullscreen pulled in hide-overlay functionality automatically. Good to know, and it makes sense. Actually, to me, fullscreen should naturally pull in persistent too, then, as clicking outside the dialog isn't practically possible (or shouldn't be).

[185driver]

@payammeyer that's right, but it's because you're using fullscreen too, which pulls in hide-overlay by default. @MajesticPotatoe was referring to a normal dialog in his comment.

[payammeyer]

Oh my mistake, thanks for the clarification, either way it’s really not a workaround for me and I would indeed call it a regression.

[185driver]

Bless @jacekkarczmarczyk for removing the p:low tag. Without a workaround, this issue is a pain. Ha. Thanks for all you guys do!

[MajesticPotatoe]

@payammeyer your issue pertains to 8697 which is marked as a regression. This issue is slightly different but does have some overlap.

[payammeyer]

@MajesticPotatoe thanks, I'll start watching that issue.

[FekihTaoufik]

I'm having the same issue here,
It seems that if the snackbar has been created inside of the dialog or outside (but still in the same component), the persistent prop does fix the problem.
But if you have the snackbar created and managed elsewhere (in Layout component for example), i'm still getting the closing trigger of any of my dialogs

[payammeyer]

@FekihTaoufik interesting observation, my snackbars are indeed created elsewhere and triggered to display via an event.

[FekihTaoufik]

It seems that anything that has a fixed position and clickable, does trigger the close:outer event of any
fullscreen dialog (even with persistent prop).

[ThomasGauthierr]

I'm facing the very same issue, any help would be greatly appreciated.

[BloodMotion]

Same issue here, with the dialog full screen component. The workaround by @185driver works but not with fullscreen props ... 😢

[185driver]

@NavidMitchell This is a fantastic workaround. Thanks for sharing it. This issue affects my apps daily (due to snackbars with clickable buttons) so your solution is a welcome relief. I modified the markup slightly after some testing, but it works the same, in case someone is interested:

<v-snackbar
  v-model="snackbar"
  bottom
>
  <div
    v-show="false"
    class="v-menu__content--active"
  />
  {{ snackText }}
</v-snackbar>

[KaelWD]

Damn that's sneaky. Note this will cause the dialog to have a higher z-index than the snackbar if the snackbar is open first.

[185driver]

Is the higher z-index issue alleviated by setting it to 1000 as @NavidMitchell suggested?

[KaelWD]

No, you should set z-index on the dialog instead.

[yusifk88]

@MajesticPotatoe Thanks. Indeed, that was noted in the issue I posted. I wasn't aware that fullscreen pulled in hide-overlay functionality automatically. Good to know, and it makes sense. Actually, to me, fullscreen should naturally pull in persistent too, then, as clicking outside the dialog isn't practically possible (or shouldn't be).

this would not be practical either, i was facing this issues and thought i could just add persist on the dialog until users started wondering why pressing escape on the keyboard dose not close the dialog, my solution now is remove the persistent from the dialog and also remove the close button from the snackbar so it timeout by it self

[185driver]

Some observations after upgrading to v2.3.0...here's an updated codepen too:

1. The workaround shared by @NavidMitchell no longer seems to work, at least for me. I'm not sure what the issue is, as I'm getting intermittent results in my project, but mostly my v-snackbar no longer displays properly when triggered within a fullscreen dialog. The structural changes to v-snackbar made in PR #11542 seem to be the reason.
2. On the bright side, the workaround is no longer needed if you add the persistent prop to v-dialog. This was the original workaround that didn't work in some cases. Now it does, but it comes with a side effect...dismissing the snackbar causes the persistent click animation to fire, which is an odd effect on a fullscreen dialog. Adding the no-click-animation prop along with the persistent prop resolves this.
3. Earlier in this thread, there was discussion of v-dialog behavior in fullscreen or non-fullscreen mode along with hide-overlay and persistent prop use. I don't know what the current v-dialog status is for these props, but my suggestion for resolving and closing this issue would be to consider automatically adding hide-overlay, persistent and no-click-animation props (their associated classes, actually) anytime the fullscreen prop is invoked. It seems natural that they would always be included in a fullscreen scenario, and would eliminate the need to add them manually.

[albertovincenzi]

@185driver

1. I tested and works but if dialogs are not fullscreen, the snackbar appears under, so its not fully visible
2. Agree, its not nice to see the animation
3. In my opinion, its not the best choice because I expect that by default, clicking on dismiss button of snackbar will only generate a single action which doesn't involve other components. Adding all that props will solve the issue but I still consider that as a workaround.