Navigation Menu

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

MudAutocomplete does not show content after first click only for server-site #3640

Closed
1 of 2 tasks
patrykplay opened this issue Jan 1, 2022 · 32 comments · Fixed by #3776 or #4375
Closed
1 of 2 tasks

MudAutocomplete does not show content after first click only for server-site #3640

patrykplay opened this issue Jan 1, 2022 · 32 comments · Fixed by #3776 or #4375
Labels
bug Something does not work as intended/expected

Comments

@patrykplay
Copy link

patrykplay commented Jan 1, 2022

Bug type

Component

Component name

MudAutocomplete

What happened?

Im using MudAutocomplete to show list of items. After upgrade MudBlazor nuget to 5.2.0, 6.0.2.. or 6.0.3 my project (Blazor Server-Site) that component always show empty content after first click. All next click works right.

For Blazor Wasm - it works fine.
For Blazor Server-Site - it does not.

Expected behavior

Show data after each click.

Reproduction link

https://github.com/patrykplay/mudblazor-autocomplete-double-click-issue

Reproduction steps

  1. Download my source code for this issue.
  2. Build and run project.
  3. Try to open MudAutocomplete lookup by first click after render.

Relevant log output

No response

Version (bug)

5.2.0, 6.0.2, 6.0.3

Version (working)

5.1.5

What browsers are you seeing the problem on?

Firefox, Microsoft Edge

On what operating system are you experiencing the issue?

Windows

Pull Request

  • I would like to do a Pull Request

Code of Conduct

  • I agree to follow this project's Code of Conduct
@patrykplay patrykplay added the triage Investigation required label Jan 1, 2022
@jsaunders92
Copy link

I am also experiencing this same issue

@Mr-Technician
Copy link
Member

Considering 5.1.5 was the last working version, I suspect the popover changes in 5.2.0 are to blame here. 6.04 (and by extension 6.0.3) also display this issue.

@just-the-benno
Copy link
Contributor

The true issue here is that the represented code is not truly async and therefore breaks the update behavior. Something that the compiler is complaining about as well.

If you restructure your code a bit and add a pseudo delay, it should work.

private  async Task<IEnumerable<Item>> ItemsSearchAsync(string searchText)
{
        await Task.Delay(1);
        return String.IsNullOrEmpty(searchText) == false ? Items.FindAll(x => searchText.Contains(x.Id.ToString())) : Items;
}

@Mr-Technician
Copy link
Member

That's odd, because the autocompletes that exhibit this issue on my projects all call asynchronous methods that use await on an ef core dbcontext. @just-the-benno

@Mr-Technician
Copy link
Member

Another issue I'm noticing after fixing the async issue with the code above: Clicking once will select an item but won't close the autocomplete. I have to click elsewhere for it to actually close.

@bindea-mihai
Copy link

Experiencing the same issue as @Mr-Technician. The same for us, we load the data with EF Core and the presented options in autocomplete are not refreshed, but the old options remain (from before the list was re-rendered).

@Mr-Technician
Copy link
Member

Do you also have issues with autocompletes opening when the form containing them submits? @bindea-mihai I am running into that as well.

@vflame
Copy link

vflame commented Feb 11, 2022

The true issue here is that the represented code is not truly async and therefore breaks the update behavior. Something that the compiler is complaining about as well.

If you restructure your code a bit and add a pseudo delay, it should work.

private  async Task<IEnumerable<Item>> ItemsSearchAsync(string searchText)
{
        await Task.Delay(1);
        return String.IsNullOrEmpty(searchText) == false ? Items.FindAll(x => searchText.Contains(x.Id.ToString())) : Items;
}

is this related to this underlying issue? dotnet/aspnetcore#22159

@andersstorhaug
Copy link
Contributor

andersstorhaug commented Feb 11, 2022

That is an interesting issue on dotnet/aspnetcore, and personally what's being suggested there would definitely be a welcome change for Blazor.

For MudAutocomplete the issue appears to be for a couple of reasons:

  • For async lifecycle methods and callbacks, if the component has been marked for render either implicitly or explicitly via StateHasChanged(), the component will render once before awaiting, and again after awaiting per Blazor docs.
  • MudBlazor popovers also use a technique/pattern that attempts to reduce unnecessary renders, via a form of locking
    • This is what I've addressed in my PR for MudAutocomplete. I don't think there's anything wrong with this approach, but, we still have to take care to not trigger extraneous renders, because they may end up "locking" out a render that should in fact occur

Edit: I had to re-read the linked docs here, because I initially had this wrong with how the framework renders. I think that the 2nd bullet here is really what the underlying issue is in this case.

@henon
Copy link
Collaborator

henon commented Apr 4, 2022

Attention everybody who was able to reproduce this bug. We had to partially revert the fix (see #4326) because it caused the autocomplete menu get stuck and stay open in BSS deployed on Azure (see #4303). We strongly recommend you to test if our partial revert (current dev branch) is causing this here bug to resurface or not. If so, we need a way to reproduce so we can find a better fix.

@andersstorhaug @bindea-mihai @vflame @jsaunders92 @Mr-Technician

@henon
Copy link
Collaborator

henon commented Apr 5, 2022

You can use this preview nuget to test: https://www.nuget.org/packages/MudBlazor/6.0.10-dev.1

@Mr-Technician
Copy link
Member

I installed the preview version and I am seeing the initial open issue described in this issue (3640) happening again. It doesn't happen with every autocomplete so I suspect it could be due to inconsistent latency between the views that the autocompletes use. @henon

@Yomodo
Copy link
Contributor

Yomodo commented Apr 5, 2022

I installed the preview version and I am seeing the initial open issue described in this issue (3640) happening again

Just ran into this, BSS

@henon
Copy link
Collaborator

henon commented Apr 5, 2022

Any way for me to reproduce it with relative certainty?

@Yomodo
Copy link
Contributor

Yomodo commented Apr 5, 2022

Any way for me to reproduce it with relative certainty?

I tried a TryMudBlazor but since the version there is 6.0.9 all is well.
By just installing the dev nuget package, ALL my AutoComplete's have the initial open issue.
Reverting the package and all is well.

@Mr-Technician
Copy link
Member

I tried a TryMudBlazor but since the version there is 6.0.9 all is well.

Try is also WASM so the issue won't appear there.

@henon I will try to make a minimal repo but it might be tricky since this issue seems to show up when pulling data from the on premises SQL servers at work.

@Yomodo
Copy link
Contributor

Yomodo commented Apr 5, 2022

@henon I will try to make a minimal repo but it might be tricky since this issue seems to show up when pulling data from the on premises SQL servers at work.

I populate my Autocompletes from local data, as in lists from memory.

@Mr-Technician
Copy link
Member

@Yomodo If you have a good reproducible example I can try as well (and hopefully henon can too)

@Yomodo
Copy link
Contributor

Yomodo commented Apr 5, 2022

Lower part is how I use it now and where the issue occurs.
Upper part is from the docs, which does NOT have the issue, I'm gonna fiddle with this to see if I can isolate the problem!

image

@henon
Copy link
Collaborator

henon commented Apr 5, 2022

Found a better fix #4375

henon added a commit to henon/MudBlazor that referenced this issue Apr 5, 2022
@Yomodo
Copy link
Contributor

Yomodo commented Apr 5, 2022

Ok, after a lot of fiddling and 5 whiskeys later, the only thing I had to do is add a small delay in the SearchFunc method!

await Task.Delay(5); // Just like in the doc examples.

So, in my case, the initial opening issue now no longer occurs with the 6.0.10-dev1 package.

However, I did run into something which is also present in 6.0.9 that may cause other issues;
Autocomplete works fine with a simple string, but acts different/doesn't work when using a class.

https://try.mudblazor.com/snippet/wYQQOokpBKMVTBFT

  1. Select a state in both Autocompletes;
    image

  2. Click the first Autocomplete,
    In the first Autocomplete the current item is shown:
    image
    The second Autocomplete does not show anything.
    image
    If CoerceText="true" it clears the selection.
    image

@henon
Copy link
Collaborator

henon commented Apr 6, 2022

Did you make sure your class has GetHashCode and Equals overwritten?

@Yomodo
Copy link
Contributor

Yomodo commented Apr 6, 2022

Did you make sure your class has GetHashCode and Equals overwritten?

Aha, I was not aware this is needed. Not mentioned in the docs.

@henon
Copy link
Collaborator

henon commented Apr 6, 2022

@Yomodo please check my new fix with this https://www.nuget.org/packages/MudBlazor/6.0.10-dev.2

Should work even without your workaround

@Yomodo
Copy link
Contributor

Yomodo commented Apr 6, 2022

Should work even without your workaround

Confirmed, no more workaround needed. Awesome job guys!

@henon henon added bug Something does not work as intended/expected bug-functional and removed triage Investigation required labels Apr 6, 2022
@Mr-Technician
Copy link
Member

The issues I was seeing on 6.0.10-dev.1 appear to be resolved.

@EmilAlipiev
Copy link

This problem still exist in 6.15.0. even on this link can be reproduced. https://try.mudblazor.com/snippet/wYQQOokpBKMVTBFT
How is that resolved? Can someone explain me if this code is wrong?

@jefffhaynes
Copy link

Agreed, this problem seems to persist for me as well.

@Yomodo
Copy link
Contributor

Yomodo commented Mar 12, 2024

Agreed, this problem seems to persist for me as well.

Adding: Strict=@false shows content after a selection was made.
Docs : Strict Mode

@jefffhaynes
Copy link

No, the content does not appear seemingly regardless of the settings. Also, strict mode is not required per the docs.

@Yomodo
Copy link
Contributor

Yomodo commented Mar 12, 2024

@jefffhaynes This is what I get:
123

@jefffhaynes
Copy link

Yeah there's clearly something weird about my setup but no idea what it is. I've had to move on for now but I'll try to come back to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something does not work as intended/expected
Projects
None yet