Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: FluentButton does not get enabled when its parent fieldset is not disabled any more #698

Closed
datvm opened this issue Sep 5, 2023 · 8 comments

Comments

@datvm
Copy link

datvm commented Sep 5, 2023

🐛 Bug Report

When a FluentButton is inside a fieldset, all of them get disabled when that fieldset is disabled which is correct. However when the fieldset is no longer disabled, the FluentButtons are still disabled.

image

💻 Repro or Code Sample

@page "/test"

<fieldset disabled="@(working)">
    <p>
        <FluentButton OnClick="WorkAsync">
            Work
        </FluentButton>

        <FluentButton>
            Button for Testing
        </FluentButton>

        <button>Button for Testing</button>
    </p>
</fieldset>

<p>
    <button disabled="@(working)">Testing Button</button>
</p>


@code {
    bool working;

    async Task WorkAsync()
    {
        working = true;
        StateHasChanged();

        await Task.Delay(1000);
        working = false;
    }
}

🤔 Expected Behavior

The FluentButtons should be enabled once the fieldset is not disabled anymore.

😯 Current Behavior

The FluentButtons are still disabled. The standard buttons are for confirming that the code works as intended and they get enabled.

💁 Possible Solution

Unknown, I tried adding extra StateHasChanged called too but it doesn't work.

🔦 Context

🌍 Your Environment

  • OS & Device: Windows 11 Pro
  • Browser Microsoft Edge
  • .NET and FAST Version 3.0.0
@dvoituron
Copy link
Collaborator

Problem

It seems to be a bug in the fluent-button web component used:

  1. By adding disabled to the fieldset, fluent-buttons are automatically set to Disabled.
  2. But when removing disabled from the fieldset, the reverse operation of re-enabling the fluent-buttons doesn't work.

Solution

A solution is to use the Disabled="@working" attribute on all FluentButtons.

<fieldset disabled="@working">
    <p>
        <FluentButton OnClick="WorkAsync" Disabled="@working">
            Work
        </FluentButton>

        <FluentButton Disabled="@working">
            Button for Testing
        </FluentButton>

        <button>Button for Testing</button>
    </p>
</fieldset>

@vnbaaij
Copy link
Collaborator

vnbaaij commented Sep 6, 2023

I recreated the bug on the FAST repo to see if we can get a fix from there: microsoft/fast#6831

@vnbaaij
Copy link
Collaborator

vnbaaij commented Nov 1, 2023

Closing this. Work around provided, formal solution will come from web-components script

@Mike-E-angelo
Copy link

Hi @vnbaaij and team, can we please get an update on this? If I understand correctly, it appears there was a PR submitted to resolve this issue in the lower layer:
microsoft/fluentui#30999

Is there a way to leverage this in this library now? I am implementing the work around but for some reason I am running into problems when I have the FluentButton in a parent element that has ShouldRender() => false and then is set back to true. Forcing StateHasChanged does not refresh the button's disabled state.

It would be ideal to turn off this fieldset functionality to simplify this scenario. Thank you for any assistance you can provide.

@vnbaaij
Copy link
Collaborator

vnbaaij commented Jul 30, 2024

There is not much to update on. The fix you linked is for the next version of the web components. If it's not possible (as far as I know) to backport that to v2.

@Mike-E-angelo
Copy link

Thank you for that update @vnbaaij and the further context. I am particularly interested in what you meant by this:

Work around provided, formal solution will come from web-components script

Are you saying that since this can no longer be backported this is no longer possible?

@vnbaaij
Copy link
Collaborator

vnbaaij commented Jul 30, 2024

Most probably not in our current version of the library. But will be fixed on the Blazor side when we move to the web components v3 with the next major version.

@Mike-E-angelo
Copy link

OK great thank you very much for that update @vnbaaij it is greatly appreciated, along with all your efforts here. 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants