1706003 - Automatic reconnect for server sent events does not work at all

Status: VERIFIED FIXED

(Core :: DOM: Networking, defect, P2)

Description

[Otto]

Attachment: code-to-reproduce.tar.gz

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I'm running a website with server sent events, over HTTP/2.

Server sent events, as described here: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

Actual results:

When the TLS connection between Firefox and my website is severed, Firefox does not try to reconnect.

I tried the same in Chrome, and Chrome does reconnect, which as far as I understand the spec, is in line with the specs for server sent events. Chrome nicely sends the "last-event-id" HTTP header upon reconnects, so my server can return events to the client that the client missed due to the temporary connection loss.

Attached is the (stand alone) NodeJS code and index.html that can be used to reproduce my bug. (Self signed cert included for your convenience so you can immediately run this yourself)

Expected results:

Firefox should reconnect automatically (and keep trying until this succeeds), after the "retry" time from the last successfully received server sent event. Upon reconnecting, Firefox should send the "last-event-id" HTTP header, with the event id of the last successfully received server sent event.

Comment 1

[Otto]

Note that in my code to reproduce, I sever the connection artificially after 5 secs, by destroying the stream. However, a CTRL-C of the NodeJS process and restarting it, also reproduces the issue. (Firefox does not reconnect, Chrome does)

Comment 2

[Rares Doghi, Desktop QA]

Hi Otto, thanks for taking the time to log this issue, Do you have a link to that website where we can try to reproduce the issue on our end, you just load the website in Firefox, disable/enable the internet connection and wait for the page to reconnect ?

I Will set a component for this issue and maybe one of our developers can take a look and they might know what the issue is.

Comment 3

[Otto]

Hi Rares. This is for a website I am developing but is not on-line yet. However, the NodeJS sources I attached allow you to run a tiny website locally yourself, with which you can reproduce the issue.

Steps:

• extract zip
• Run website: node server.js
• open firefox and navigate to https://localhost:8080 where the server is listening. You'll see a HTML page that is getting updated with server sent events every second
• Wait 5 secs so the in-built error in server.ts triggers the connection to be closed.
• Firefox does not reconnect -- which is the issue I'm reporting
• Try Chrome to see the correct behavior

Comment 4

[Otto]

Attachment: code-to-reproduce.tar.gz

Comment 5

[Otto]

Attachment: code-to-reproduce.tar.gz

Comment 6

[Rares Doghi, Desktop QA]

Hi Otto, Thanks so much for the extra steps and files, those made it so much easier to reproduce it on my end, Ill update the flags for this issue. Thanks again!

Comment 7

[(inactive) Nihanth Subramanya [:nhnt11]]

This is interesting because we have code to perform the reconnect here.

I haven't yet tried to step through the code and see why we're not doing the reconnect. In any case, this sounds like a P2.

Comment 8

[Luca Casonato [:lucacasonato]]

I just ran into this too. It's definitely an interop issue - Chrome and Safari both reconnect in the case of a connection failure. Downstream bug report that I ran into this through: https://github.com/denoland/fresh/issues/694. Additionally the red herring error message printed on disconnect (see https://bugzilla.mozilla.org/show_bug.cgi?id=1789252) makes this rather difficult for developers to debug.

Comment 9

[Brian Grinstead [:bgrins]]

I can reproduce this easily as well following the instructions from https://fresh.deno.dev/docs/getting-started/create-a-project:

deno run -A -r https://fresh.deno.dev my-project
cd my-project
deno task start

If I open localhost:8000 in Firefox I get the error "The connection to http://localhost:8000/_frsh/alive was interrupted while the page was loading." and the hot module reload fails (for example if modifying the content in routes/index.tsx the page doesn't auto update in Firefox but it does in other browsers)

Comment 10

[Brian Grinstead [:bgrins]]

I'm not sure if this is the same root cause but I can reproduce broken hot module reload with a new Next 13 app. STR:

 # give it the name `create-next-app-results`
npx create-next-app@latest --experimental-app
cd create-next-app-results
npm run dev

Alternatively, I pushed this up to https://github.com/bgrins/create-next-app-results so that repo can be cloned and npm install && npm run dev

After doing this, if I open localhost:3000 in Chrome and Firefox, then edit app/page.module.css the change is immediately picked up in Chrome but requires a reload in Firefox.

Comment 11

[Greg Hess]

Flagging for webcompat triage as server reconnect is working in Chrome and Safari.

Comment 12

[Sunil Mayya]

I was able to reproduce the issue with (In reply to Otto from comment #3)

Hi Rares. This is for a website I am developing but is not on-line yet. However, the NodeJS sources I attached allow you to run a tiny website locally yourself, with which you can reproduce the issue.

Steps:

• extract zip
• Run website: node server.js
• open firefox and navigate to https://localhost:8080 where the server is listening. You'll see a HTML page that is getting updated with server sent events every second
• Wait 5 secs so the in-built error in server.ts triggers the connection to be closed.
• Firefox does not reconnect -- which is the issue I'm reporting
• Try Chrome to see the correct behavior

Thank you for these steps. Reproducing the issue was straightforward with these steps.
The problem was that we were not re-triggering connection for the network error triggered in this scenario (NS_ERROR_NET_PARTIAL_TRANSFER).

The following patch have fixed the issue.

@@ -843,12 +845,15 @@ EventSourceImpl::OnStopRequest(nsIReques
       aStatusCode != NS_ERROR_NET_TIMEOUT &&
       aStatusCode != NS_ERROR_NET_RESET &&
       aStatusCode != NS_ERROR_NET_INTERRUPT &&
+     aStatusCode != NS_ERROR_NET_PARTIAL_TRANSFER &&
       aStatusCode != NS_ERROR_PROXY_CONNECTION_REFUSED &&
       aStatusCode != NS_ERROR_DNS_LOOKUP_QUEUE_FULL) {

I will discuss this further to check if more network errors must be included.

Comment 13

[Sunil Mayya]

Attachment: Bug 1706003 - extend network error checks in EventSourceImpl::OnStopRequest. r=#necko

Comment 14

[Sunil Mayya]

(In reply to Brian Grinstead [:bgrins] from comment #9)

I can reproduce this easily as well following the instructions from https://fresh.deno.dev/docs/getting-started/create-a-project:

deno run -A -r https://fresh.deno.dev my-project
cd my-project
deno task start

If I open localhost:8000 in Firefox I get the error "The connection to http://localhost:8000/_frsh/alive was interrupted while the page was loading." and the hot module reload fails (for example if modifying the content in routes/index.tsx the page doesn't auto update in Firefox but it does in other browsers)

Hello Brian,

I am able to fix the above behavior (hot module reload failure) with my patch meant for the original problem mentioned in the bug. However, while reproducing the issue I never encountered any http://localhost:8000/_frsh/alive was interrupted errors.
I would like to check with you if there are any additional tests that you would like me to run before landing my patch.
Thanks

Comment 15

[Brian Grinstead [:bgrins]]

Attachment: Screenshot 2023-01-04 at 8.39.20 AM.png

(In reply to Sunil Mayya from comment #14)

(In reply to Brian Grinstead [:bgrins] from comment #9)

I can reproduce this easily as well following the instructions from https://fresh.deno.dev/docs/getting-started/create-a-project:

deno run -A -r https://fresh.deno.dev my-project
cd my-project
deno task start

If I open localhost:8000 in Firefox I get the error "The connection to http://localhost:8000/_frsh/alive was interrupted while the page was loading." and the hot module reload fails (for example if modifying the content in routes/index.tsx the page doesn't auto update in Firefox but it does in other browsers)

Hello Brian,

I am able to fix the above behavior (hot module reload failure) with my patch meant for the original problem mentioned in the bug. However, while reproducing the issue I never encountered any http://localhost:8000/_frsh/alive was interrupted errors.
I would like to check with you if there are any additional tests that you would like me to run before landing my patch.
Thanks

I just double checked the STR on the latest Firefox Nightly and still see the error (see screenshot). If you aren't seeing the error, I'm curious if when you edit a file while having localhost:8000 open if it instantly updates? For example, go to ./routes/index.tsx and edit the paragraph. I can check with your patch applied as well, but it would be good to know if things are actually working properly on your computer or if the error message is just inconsistently showing up.

Comment 16

[Brian Grinstead [:bgrins]]

OK, I've confirmed with https://phabricator.services.mozilla.com/D165612 applied that the hot module reload for Fresh starts working. Note that I still see the error message in DevTools which is not great but less of a problem and something that may be tracked elsewhere.

Comment 17

[Brian Grinstead [:bgrins]]

(In reply to Brian Grinstead [:bgrins] from comment #16)

OK, I've confirmed with https://phabricator.services.mozilla.com/D165612 applied that the hot module reload for Fresh starts working. Note that I still see the error message in DevTools which is not great but less of a problem and something that may be tracked elsewhere.

Ah, right - Bug 1789252 tracks the error message

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cb4019cce848
extend network error checks in EventSourceImpl::OnStopRequest. r=necko-reviewers,valentin

Comment 19

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/cb4019cce848

Comment 20

[Rares Doghi, Desktop QA]

This issue is Verified as fixed in our latest Nightly build 110.0a1 (2023-01-06).