1620750 - ws-over-h2 works well but after h2 connection closure new ws connections face long delay before starting

Status: RESOLVED INVALID

(Core :: Networking: WebSockets, defect)

Description

[Andy Green]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

1. Visit, eg, https://libwebsockets.org/server-status/

This works well and opens a ws connection back to the server over rfc8441 ws-over-h2 that operates properly. First update might take 5s, but the body should be white indicating it's connected while it waits.

2. Open a second tab to the same site, it's opening immediately and nicely

3. Kill the connection... I tested it by change wifi AP... after a few seconds it understood the old ws connection was dead and grey out the browser body

4. ... this is the problem... hit enter in the address bar to reload the page.

Actual results:

Ffox seems to load the page but instead of opening the ws connection directly, enters into a state where it has not opened the ws connection but is waiting... this can go on for minutes. After some time, the ws connection opens normally and after that, you can open a second tab to the same server normally etc.

It seems to wrongly remember there was already an h2 network connection to that endpoint, and try to use it... but it's dead already.

Expected results:

Same as the first time you used the site, it should make the ws connection and then on that example URL, after a few seconds show results.

Ffox should understand that a dead h2 connection should not be listed any more as a candidate for "ridesharing" future h2 streams, without making the user wait while it realizes that's not going to work.

Chrome set to use RFC8441 ws-over-h2 does not exhibit these behaviours, and just works. For that reason and the fact the server isn't getting the ws connection, I think this problem is living in ffox alone.

Comment 1

[Daniel Bodea [:danibodea]]

I cannot reproduce your behavior. These are my steps:

1. Open Firefox Release v73.0.1.
2. Connect to the internet.
3. Load 2 different tabs with this site: https://libwebsockets.org/server-status/
4. Remove internet connection (I turned off the wifi);
5. Wait for the focused tab to get grayed out (Disconnected).
6. Refresh the tab.
   Buggy behavior: The page loads.
   Actual and expected behavior: The page does not load.

I think I might have not understood the steps very well. Will you please correct them so I can reattempt to reproduce and confirm your issue?

Comment 2

[Andy Green]

Yes the misunderstanding is that I did not just turn off the wifi. I switched to a different AP where the PC received a different IP address. I had Internet connectivity before, and after doing that.

The bug is coming because although Firefox understands well that the original h2 connection is dead after that, since the JS on the page sees the ws connection is closed and greys out the page, if you try to load the page again, eg, in a new tab, or by pressing enter in the address bar on tab where it was before:

• it loads the http and starts the script fine. The script tries to open a ws connection back to the server again.

• there is a loooong delay of a minute or more before the ws opens successfully and proceeds

• the ws-over-h2 code in firefox seems to still kind of believe the h2 connection from the first session is still alive somehow, causing the delay (that's a guess... all I know is the delay).

You're trying to reproduce the delay in opening the ws after the wifi AP was switched and the first connection to the site definitely dead.

Comment 3

[Daniel Bodea [:danibodea]]

I cannot reproduce a delay. These are my steps:

1. Open Firefox.
2. Connect to the one mobile hotspot.
3. Load 2 different tabs with this site: https://libwebsockets.org/server-status/
4. Connect to another hotspot.
5. Wait for the focused tab to get grayed out (Disconnected).
6. Refresh the tab.
   Buggy behavior: The page loads after a delay.
   Actual and expected behavior: The page loads without a delay.

@Andy: I still cannot confirm it since I cannot reproduce. Can you please attempt to reproduce the issue in safe mode?
@nhi: Can you please have an opinion on this issue? Maybe confirm it if it's valid or help with STR?

Thank you for your contribution!

Comment 4

[Andy Green]

"Safe mode" is like for Windows? I'm testing this on Linux (Fedora 31 with Fedora 31 Firefox package).

I do have a windows VM, I will try it there later. And I will look a making a desktop video type thing if it will help.

Comment 5

[Daniel Bodea [:danibodea]]

I mean the safe mode of Firefox, not of the OS (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode).

Comment 6

[Andy Green]

Huh... I can't reproduce it atm either. I restarted Firefox in "safe mode", it worked. I restarted it with extensions enabled, it worked.

Last update of ffox was 23rd Feb.

I guess I should close this until / unless I see it coming again.

Well.... it's good news I guess... thanks for the help and sorry for what at the moment seems to be noise.