Codecov Report

Attention: Patch coverage is 79.06977% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 88.90%. Comparing base (74e5562) to head (048e15d).
Report is 5 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #8334      +/-   ##
==========================================
+ Coverage   88.64%   88.90%   +0.25%     
==========================================
  Files         407      407              
  Lines       12179    12218      +39     
  Branches     2431     2440       +9     
==========================================
+ Hits        10796    10862      +66     
+ Misses        858      828      -30     
- Partials      525      528       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

We would need to cover the new lines with unit tests, if possible to simulate that the mouse is on the snackbar.
Also adding @henon for review.
I'm also not sure about the UserCanAffectTransitions name, it's like saying me I can influence the state but what state and when? Also since it's true does it means that this feature is enabled by default? If yes it should be the opposite. But I will let @henon to decide about the naming, Really shame that CommonSnackbarOptions has no XML comments at all what this options do.

I think this is a pretty useful feature and I'd say we can even make it the default. I mean, what is the worst that can happen to any existing apps, that the user hovers over a message and it will not fade. I wouldn't call that a breaking change.

Parameter name ideas: KeepVisibleThroughInteraction, HoverToPreventFadeout, AllowUserToPreventFadeout, UserCanPreventFadeout or just Interactive.

PreventTransitionOnInteraction is another option (default false). I wouldn't mind dropping the API completely since it just makes sense to me.

@ScarletKuro @henon @mikes-gh

So remove the option and make this new behavior hardcoded? Everything else looks good?

Does anyone has pointers on testing mouse hover and touches?

@danielchalmers what about the use-case of clicking a snackbar message to hide it? That would collide with this new behavior, right?

Does anyone has pointers on testing mouse hover and touches?

Any mouse or touch event can be simulated easily in bUnit.

@danielchalmers what about the use-case of clicking a snackbar message to hide it? That would collide with this new behavior, right?

That will perform the same action as the close button and is thus uncancellable and ignores further interaction.

So how do you do it on mobile? Touch and keep touching to keep the message from hiding?

So how do you do it on mobile? Touch and keep touching to keep the message from hiding?

A touch will keep it visible until somewhere else is touched

Doesn't bUnit have the MouseOver / MouseOut methods? https://bunit.dev/api/Bunit.MouseEventDispatchExtensions.html
for touch https://bunit.dev/api/Bunit.TouchEventDispatchExtensions.html we probably need the TouchLeave / TouchEnter

So how do you do it on mobile? Touch and keep touching to keep the message from hiding?

A touch will keep it visible until somewhere else is touched

Ok, I think in this scenario there is a collision between the use-cases and we would need the property. Some may want to just touch messages to make them go away on mobile.

So how do you do it on mobile? Touch and keep touching to keep the message from hiding?

A touch will keep it visible until somewhere else is touched

Ok, I think in this scenario there is a collision between the use-cases and we would need the property. Some may want to just touch messages to make them go away on mobile.

@danielchalmers Does this PR change the touch interaction? Touching twice to close a Snack bar would cause confusion.

@danielchalmers Does this PR change the touch interaction? Touching twice to close a Snack bar would cause confusion.

@mikes-gh @henon

just posted an example above. clicking/touching a clickable snackbar still closes it like normal. touching a regular snackbar keeps it open. anything that calls the close event will not let the animation be cancelled

i did not intend on making any UI/UX breaking changes so if any are found I will fix them

Sounds good, as long as it is well documented.

Sounds good, as long as it is well documented.

@henon Added this:

What other kind of documentation were you thinking?

I'll add tests after #8281 to avoid conflict. Anything I can do to help that PR? Not trying to rush anyone.

I'll add tests after #8281 to avoid conflict. Anything I can do to help that PR? Not trying to rush anyone.

I will try to look it tmr

What other kind of documentation were you thinking?

For instance the difference in behavior between closable and non-closable snackbar messages could be explained.

And just to make it clear, I think from the discussion we can follow that we don't need a property to disable this new behavior as it doesn't interfere with closable messages. Do you agree @mikes-gh and @ScarletKuro? Thumbs up if you agree please.

May I suggest a little refinment?

Change:
It provides the user with a temporary closable snackbar
To:
It provides a temporary and closable snackbar

@henon @ScarletKuro Thank you so much for the work on #8281

I've done more on the snackbar and added comprehensive tests. Should be ready!

New wording

I think it's much clearer

Thanks Daniel