1729219 - Firefox aborts its https request silently

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Dyne Hash]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

The steps to reproduce the problem are a bit complicated, as it occurs in the Redmine of the Company I work. So I won't be able to provide data sensitive to identification.

I am trying to display a Time Spent report which can be accessed via the URL https://redmine.domain.com/time_entries.
On the server I use the report usually takes about 40 to 50 seconds to be generated. I can't get any information from his browser not displaying the report screen.

I've tried mapping via Debugger or Network, but it doesn't show any output about the problem, it just seems to give up on the request.

Actual results:

Show Redmine Time Entries report

Expected results:

Empty screen or permanence of the current page.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Netmonitor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Dyne Hash]

Sorry I reversed the information, the correct is:

Actual results:

Empty screen or permanence of the current page.

Expected results:

Show Redmine Time Entries report

Comment 3

[Dyne Hash]

I would like to add some information.
Chromiun-based browsers had no problems.

In the web server(nginx) log it shows the following message:

17x.2x5.5x.2x4 - - [05/Sep/2021:01:16:47 -0300] "GET /time_entries HTTP/1.1" 504 192 "https://redmine.domain.com/projects" "Mozilla/ 5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0"
17x.2x5.5x.2x4 - - [05/Sep/2021:01:17:12 -0300] "GET /time_entries HTTP/1.1" 504 192 "https://redmine.domain.com/projects" "Mozilla/ 5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0"

I've already tried increasing the timeout of Nginx settings, but to no avail. I believe it was some change made in a few weeks and it doesn't affect Firefox ESR and Nightly.

I just did some more tests and from version 87 or older it works.

I can't promise, but ideally I would provide an equal environment without the sensitive data for developers to test. My time is so short.

Comment 4

[Marcela (Please NI request to Brindusa Tot)]

Hi Dyne!
It is a bit difficult to try to reproduce the problem without having more specific data. If possible, could you generate a test case for us to replicate the same error?
You can also check the Browser Console for errors (Hamburger Menu> More Tools> Browser console) and attach them.
I will change the component to have a starting point and give visibility to the corresponding team.
Also, Bugzilla has a section "Security" where you can allow access to whom you consider necessary.
Thanks!

Comment 5

[Kershaw Chang [:kershaw]]

Hi Dyne,

Could you try to capture a http log?
You could send the log directly to my email, if you don't want to make the log public.

Thanks.

Comment 6

[Dyne Hash]

Attachment: HTTP Logging

Comment 7

[Dyne Hash]

Kershaw,

I have attached the HTTP Logging file. It took me a while because I didn't know the tool.
I collected the log by opening only the site in question. The logs with other tabs were getting huge =).

If I can detect the failure, it will be very good, if I can't I will be creating an environment and I can create accounts for those who want to investigate the problem. It should take at least 3 days as I need to load data.

I'm waiting, before starting to create the environment.

Thanks!

Comment 8

[Kershaw Chang [:kershaw]]

Thanks for the log. It shows there is one http request failed because of network timeout.

2021-09-07 17:55:33.984000 UTC - [Parent 6012: Socket Thread]: V/nsHttp Http3Session::ProcessEvents - ConnectionClosed error=804b000e
2021-09-07 17:55:33.984000 UTC - [Parent 6012: Socket Thread]: V/nsHttp HttpConnectionUDP::CloseTransaction[this=1ec41f91f10 trans=1ec425bec00 reason=804b000e]
2021-09-07 17:55:33.984000 UTC - [Parent 6012: Socket Thread]: V/nsHttp Http3Session::Close [this=1ec425bec00]
2021-09-07 17:55:33.984000 UTC - [Parent 6012: Socket Thread]: V/nsHttp Http3Session::Closing [this=1ec425bec00]
2021-09-07 17:55:33.984000 UTC - [Parent 6012: Socket Thread]: V/nsHttp nsHttpTransaction::Close [this=1ec4aa5d800 reason=80004004]

Dragana, could you also take a look? Do we want to ask the reporter to provide neqo log?
Thanks.

Comment 9

[Dragana Damjanovic [:dragana]]

You wrote that it takes 40-50s to generate a response. This is probably caused by our bug in HTTP/3 code that should be fixed in version 93.

neqo was not keeping a connection alive when there are outstanding requests and that was causing the connection to timeout.

Which version of Firefox are you using?
Can you try with Nightly or the newest Beta, version 93, (releases yesterday)?
Let me know if that fixes the issue.
Thank you!

Comment 10

[Dyne Hash]

Previously I tested with these versions:

It works:
Firefox ESR 78.13.0
Firefox 87.0
Nightly 93.0 Alpha 1 Pre

Does not work:
Firefox 88, 89, 90, 91, Developer 92.0 Beta 2

I tested it with the versions you recommended and the problem doesn't occur.
Firefox Nightly 94.0a1
Firefox Beta 93.0b2

That Cool! The problem has already been identified and correction in progress.
Thanks.

Comment 11

[Dragana Damjanovic [:dragana]]

Thank you for reporting the issue and testing it!

Fixed by 1724196 and PR 1160

Comment 12

[Dyne Hash]

Dragana,

To better understand. Will the bug be fixed only when release 93? Or there is the possibility of happening before.
I suspect that as it's not a critical issue I should wait hahaha

I was happy to report the bug, I was very well received hahaha

Thank you!

Comment 13

[Dragana Damjanovic [:dragana]]

It will be only fixed after 93 release.