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

Firefox shows "attempting to reconnect to server" on opening application; #28592

Open
Stanislav-Beresnev opened this issue Dec 11, 2020 · 17 comments
Labels
affected-medium This issue impacts approximately half of our customers area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug. Pillar: Technical Debt severity-minor This label is used by an internal tool
Milestone

Comments

@Stanislav-Beresnev
Copy link

Describe the bug

I have the same issue as that #16739 but in my case "attempting to reconnect to server" is displayed when I open the application or press F5 to refresh the page. Sometimes, I faced it when navigating to another page. See the attached picture.

Firefox_bug

To Reproduce

Steps to reproduce the behavior:

  1. Using ASP.NET core 3.0/3.1 or .NET 5.0
  2. Create a new server side blazor project
  3. Run the program in firefox

Expected behavior

The "attempting to reconnect to server" error message is not showed.

Further technical details

  • ASP.NET core 3.0/3.1 or .NET 5.0
  • Microsoft Visual Studio Professional 2019 Version 16.8.1, Firefox v. 83.0 (64bit)
@mkArtakMSFT mkArtakMSFT added the area-blazor Includes: Blazor, Razor Components label Dec 11, 2020
@javiercn
Copy link
Member

@Stanislav-Beresnev thanks for contacting us.

@captainsafia do you have any ideas here? We believe this is similar to something you worked on recently.

@javiercn javiercn added this to the Next sprint planning milestone Dec 11, 2020
@ghost
Copy link

ghost commented Dec 11, 2020

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@captainsafia
Copy link
Member

@Stanislav-Beresnev Can you try to repro the issue on the latest version of .NET 5 and ASP.NET 3.2 respectively? I'm unable to repro on the latest version with Firefox 81.0.

We shipped some fixes to the disconnect process in the latest patch releases.

@Stanislav-Beresnev
Copy link
Author

@captainsafia I can still reproduce this, but I used the latest version of Firefox - 84.0. However, now I can only see this message after I refresh the page several times (5-10).

@ponchautf
Copy link

Hi,
I also have this issue with Firefox (v84.0.2) on Mac OS.
My app is a classic Asp.net core MVC application (.net core 3.1 using controller & cshtml views) with some server blazor components.

I can clearly see the message each time I navigate to another View. It's displayed less than a second but it's annoying.
Is there a way to avoid this?

this don't occurs on Google chrome (not yet tested on edge or safari)

@SteveSandersonMS SteveSandersonMS added affected-medium This issue impacts approximately half of our customers bug This issue describes a behavior which is not expected - a bug. severity-minor This label is used by an internal tool labels Jan 26, 2021 — with ASP.NET Core Issue Ranking
@ghost
Copy link

ghost commented Aug 3, 2021

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

@mikoskinen
Copy link

Started seeing this today. Didn't happen yesterday (Firefox 97.0). What changed was that I changed the project to target .NET 6 instead of Core 3.1.

Still doesn't happen with Edge but happens every time when I click a link with Firefox. It seems that if it takes the server 1 second to process the request, I see the "attempting to reconnect to server" for that second.

@Bouke
Copy link
Contributor

Bouke commented Mar 1, 2022

I'm posting here as @mkArtakMSFT marked my bug reports as duplicate of this one. I've found that there are two separate issues w.r.t. Firefox that cause this dialog to appear, both solved with the same workaround.

Issue 1: Firefox temporarily shows reconnect dialog while navigating to new page (or reloading page)

On Firefox the reconnect dialog temporarily appears while navigating to a new slow page and it disappears while the browser is still waiting on a response from the server. For example on a page that takes 3 seconds to render on the server side:

  1. Browser starts loading new page
  2. Reconnect dialog appears immediately
  3. After ~1 second the reconnect dialog disappears
  4. After ~3 seconds the new page appears

This is very confusing for the user, as the reconnect dialog makes no sense in the context of the page navigation: once the reconnect dialog appears the browser is still waiting for the new page.

I think the issue is with Firefox closing the websocket as soon as the browser starts the navigation. Blazor is still running on the current page and tries to reconnect. Then when the new page is loaded that connection is then dropped again. I believe the following log displays this:

Issue 2: Reconnect modal displays immediately in Firefox upon navigation

The problem seems to be that Firefox executes both this.modal.style.visibility="hidden" and this.modal.style.visibility="visible" in the same reflow. As a result, the css transition is not triggered. When I change the setTimeout delay from 0 to 10 ms the transition is triggered and the delay of 500ms (+10) is respected.

Workaround

A custom reconnect dialog with a longer delay works around both issues:

  • The longer delay (e.g. 5 seconds) hides the reconnect that happens during page unload.
  • The custom reconnect dialog will already be part of the DOM, so the CSS transition delay is applied correctly on unload.

@vindberg
Copy link

It seems like the reconnection issue with Blazor is growing! Can you please consider fixing this vital error in version 7.0! Im so sad to see it pushed to 8.

@Liebeck
Copy link

Liebeck commented Mar 3, 2023

I ran into the same issue today. Seems to be fixed with

 services.AddServerSideBlazor()
            .AddHubOptions(options =>
            {
                options.ClientTimeoutInterval = TimeSpan.FromSeconds(5);
            });

@obiwanconobi
Copy link

obiwanconobi commented Mar 3, 2023

I ran into the same issue today. Seems to be fixed with

 services.AddServerSideBlazor()
            .AddHubOptions(options =>
            {
                options.ClientTimeoutInterval = TimeSpan.FromSeconds(5);
            });

This didn't work for me, in fact it made it worse on other browsers

@mohaaron
Copy link

I am also researching a very similar issue except in my case it only happens during the logout process when a button is clicked that navigates to the Logout.cshtml file where HttpContext.SignOutAsync(....) is called. When the button is clicked I immediately get the reconnecting message. Everything else is working as expected which differs from this posts scenario.

@ponchautf
Copy link

Sometime these error are due to 500 server error.
Debug your app (make sure that you stop on any errors’ not just your code)
You will probably find that an exception is raised somewhere

@ghost
Copy link

ghost commented Dec 13, 2023

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

@zacuke
Copy link

zacuke commented Mar 12, 2024

Hello, I am experiencing this intermittent reconnect dialog when the server is not having any connection issues. It seems to happen mostly in Firefox, especially on logout. In general this makes Blazor a difficult framework to recommend to management as they don't have an appreciation of the finer details regarding Firefox having poor support for the onBeforeUnload event, or that a Websocket is being closed too early, or some kind of CSS race condition is happening, or any of that kind of stuff. I should have created a plain Razor pages app, and I might have to go back to that, but I'm pushing forward with Blazor as I do love the technology from a theoretical stand point.

The suggested workarounds above don't seem to work, or maybe I don't understand them correctly. options.ClientTimeoutInterval = TimeSpan.FromSeconds(5); definitly isn't correct, as that reduces the ClientTimeoutInternal from 30 to 5 seconds and causes the reconnect panel to flash much more often.

Regarding Firefox executes both this.modal.style.visibility="hidden" and this.modal.style.visibility="visible" in the same reflow. - exactly what CSS or JavaScript should be changed? Are we to implement a custom CircuitHandler and add it via .AddCircuitHandler<CustomCircuitHandler>();

In summary, could somebody provide a more comprehensive workaround guide? I think most of us don't mind the extra work to get some cool tech like Blazor working reliably, but the default reconnect splash message is a real black eye on an otherwise amazing framework.

Thanks to all for the continued discussion regarding this long standing annoyance.

Edit: I found this fairly simple work around below, although it has the side effect of removing the reconnect message altogether. The site I'm building is fairly stateless and has forced navigation, and this can be added per page so on the pages where I do need a continuous connection I can exclude this div.

<!-- hide blazor disconnection msg -->
<div id="components-reconnect-modal"></div>

Edit 2: I'm studying the fundamentals here most notably the section on Handle errors and SignalR. I understand that with the web socket broken, the site is essentially dead in the water, but I think the main issue is that Blazor's error messages are quite noisy and in your face by default, and it's not at all obvious how to tone them down. Traditional frameworks fail quietly a lot of times and while that can be more difficult to trace down compared to Blazor's noisy errors, people are used to the web working the traditional way.

Edit 3: OK so, for my case a possibly better work around is to turn off the auto start of blazor.js in the first place. I make sure my static content is per-rendered fully and not rely on things that require client round trip, like protected override void OnAfterRender. Now the site is behaving more like a traditional web app. I can use the Blazor pre-rendering pipeline so I don't have to recreate the site as Razor pages, and finally I don't have to disable any errors. If I get into dynamic content, I'll have the option to start up the SignalR pipeline. Now management is happy because our static content doesn't show errors needlessly and I can justify on the interactive pages, if an error is seen, it makes sense the application has lost connection. See here for the full scope of starting Blazor manually.

In _Layout.cshtml
<script src="_framework/blazor.server.js" autostart="false"></script>

Then on specific page where you need the full power of blazor:

<script>
  document.addEventListener("DOMContentLoaded", function() {
    Blazor.start();
  });
</script>

@Bouke
Copy link
Contributor

Bouke commented Mar 13, 2024

Regarding Firefox executes both this.modal.style.visibility="hidden" and this.modal.style.visibility="visible" in the same reflow. - exactly what CSS or JavaScript should be changed? Are we to implement a custom CircuitHandler and add it via .AddCircuitHandler<CustomCircuitHandler>();

Let me try and explain what's happening by default:

  1. The framework detects a page unload
  2. The framework will check if there is a custom reconnect modal
  3. There is none, so it'll inject one with visibility=hidden
  4. Then changes that to visibility=visible
  5. Firefox sees 3 and 4 happening at the same time (same reflow), so it doesn't trigger the css animation, thus the modal directly appears after 4.
  6. The navigation happens and the new page is shown

So by having a custom reconnect modal you solve the problem of step 5:

  1. The framework detects a page unload
  2. The framework will check if there is a custom reconnect modal
  3. There is one, so nothing to inject.
  4. Then changes that one to visibility=visible
  5. Firefox triggers the css animation, causing the modal to appear after some time
  6. The navigation happens before the modal appears and the new page is shown

For more information on having a custom reconnect modal: https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/signalr?view=aspnetcore-3.1#reflect-the-server-side-connection-state-in-the-ui

@zacuke
Copy link

zacuke commented Mar 14, 2024

I had already upgraded the project sdk reference to .net 8 a few weeks ago, but today I realized I am still on old style Blazor Server. So I also upgraded to Blazor web app per these instructions: https://learn.microsoft.com/en-us/aspnet/core/migration/70-80?view=aspnetcore-8.0&tabs=visual-studio#update-a-blazor-server-app

This cleans up a lot of the behavior of things and it seems what I was trying to do is built-in now via @rendermode InteractiveServer

Bouke, thanks for that information I will look into having a custom reconnect modal to resolve the issue with Firefox still showing a Reconnect error on page navigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected-medium This issue impacts approximately half of our customers area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug. Pillar: Technical Debt severity-minor This label is used by an internal tool
Projects
None yet
Development

No branches or pull requests

14 participants