MudTooltip: Add Disabled parameter

[Yomodo]

Description

Resolves #8842

How Has This Been Tested?

Added 3 unit tests
Added 1 visual test

Type of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (fix or improvement to the website or code docs)

Checklist

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.21%. Comparing base (28bc599) to head (df46ea4).
Report is 154 commits behind head on dev.

❗ Current head df46ea4 differs from pull request most recent head a31dc31. Consider uploading reports for the commit a31dc31 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #8876      +/-   ##
==========================================
+ Coverage   89.82%   90.21%   +0.38%     
==========================================
  Files         412      424      +12     
  Lines       11878    12286     +408     
  Branches     2364     2406      +42     
==========================================
+ Hits        10670    11084     +414     
+ Misses        681      669      -12     
- Partials      527      533       +6     

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

[danielchalmers]

Good idea, I wonder why it was never added before.

I think the test should check onmouseenter too and explicitly enable ShowOnHover and ShowOnFocus for the corresponding tests to ensure it's capturing the right context. The Visible property should never be set to true while disabled and that should be tested as well.

[Yomodo]

The Visible property should never be set to true while disabled and that should be tested as well.

@danielchalmers Do you mean I need to modify/add the logic in the Visibility setter that prevents setting when disabled
or only ensure (test) that Visibility never gets changed when toggling the tooltip disabled state?

[danielchalmers]

Do you mean I need to modify/add the logic in the Visibility setter that prevents setting when disabled or only ensure (test) that Visibility never gets changed when toggling the tooltip disabled state?

I was thinking that the Visible property shouldn't be set to true (inside HandleMouseEnter, HandleFocusIn, HandleMouseUp) if Disabled == true to avoid a misleading state since it's not actually visually rendered.

I'm not sure what should happen if the user uses the Visible setter to make it explicitly true while Disabled == true 🤔

[Yomodo]

I was thinking that the Visible property shouldn't be set to true (inside HandleMouseEnter, HandleFocusIn, HandleMouseUp) if Disabled == true to avoid a misleading state since it's not actually visually rendered.

All 5 HandleXXX methods set the Visible state.
However, the entire MudPopover is skipped from rendering when Disabled == true, so I don't see an issue here.
(Of course I might miss something)

I'm not sure what should happen if the user uses the Visible setter to make it explicitly true while Disabled == true 🤔

I believe that nothing should happen when Disabled == true and other properties are set.
I'm assuming this behavior also applies to all other MudBlazor components.

[danielchalmers]

My point is from a public API perspective where someone might rely on the Visible property to know whether or not the tooltip is actually open on the screen

[danielchalmers]

Do you think you could take a look at #4466 as well? Seems like a simple fix.

[Yomodo]

My point is from a public API perspective where someone might rely on the Visible property to know whether or not the tooltip is actually open on the screen

By default Disabled == false, so no harm done.
Once people are aware of this new parameter they'll adjust their logic?

[henon]

In all other components Disabled prevents user interaction via mouse / keyboard. So this implementation is ok, we don't have to concern ourselves with the fact that the library consumer can force it open via the Visible parameter, that may be exactly what they want and lies entirely in their own responsibility.

[henon]

Thanks Yomodo! FYI @ScarletKuro