1842429 - UI broken and doesn't show any sort of error for failed POST request, "Network" inspect console also broken with no helpful info on the problem

Status: UNCONFIRMED

(DevTools :: Netmonitor, defect, P3)

Description

[Ellie]

Attachment: Screenshot from 2023-07-09 11-04-17.png

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

Steps to reproduce:

I found that for a particular upload attempt of mine, the "Network" inspect console seems completely useless for aborted POST request, since it doesn't show any kind of error or helpful info on the problem. It just shows a partial upload size and the request just stops, nothing at all in the console on what even happened, no server error, connection error, any info on why it just decided to halt early and not show any server response. I don't think that's a useful way for the network inspect to behave.

1. Open "Network" inspect tab
2. Do a POST request that for some reason I can't tell you (since the console shows nothing) aborts

Actual results:

no useful info whatsoever, not even a clear indication that the request didn't complete other than the upload size being mysteriously wrong

Expected results:

detailed info on why the request aborted with the exact connection or server error

Comment 1

[Ellie]

Attachment: Opera showing full page error after the POST request fails

I tested this in Opera, and it actually shows a full page error once the POST request fails. Given I submitted a plain old no-javascript POST form with a mouse click, that seems like the correct behavior. Opera also shows a proper error entry in the network console. Firefox on the other hand just quietly aborts showing the incomplete request with no error in the inspect tab whatsoever and leaving the page up untouched with no error either, as if I never had even clicked the submit button. So this doesn't seem to be working as expected on multiple layers, not just the inspect console.

Comment 2

[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 correct in case you think the bot is wrong.

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

Thanks Ellie for reporting this issue.
Can you tell us on which website you are seeing this, with precise steps to reproduce the issue?

Comment 4

[Ellie]

This is an internal admin area, and it's really a bit frustrating and makes me want to switch the browser given Opera manages. Not managing to simply upload a larger file is a pretty severe shortcoming, sadly.

Also, this happens with any normal request too, apparently, just enter an address into the URL bar and press enter and if your internet is bad enough Firefox will just randomly stop loading, no error, no nothing, and pretend you never did anything. So something with request handling with bad internet seems very wrong on a fundamental level.

Comment 5

[Julian Descottes [:jdescottes]]

What do you mean by bad internet: is it slow, it disconnecting frequently? More information can help us to reproduce your issue.

Also you could try to open the Browser Toolbox: https://firefox-source-docs.mozilla.org/devtools-user/browser_toolbox/index.html (make sure to switch to "Multiprocess" mode) and see if there is any additional information either in the Console or Network tab. If the error is a Firefox issue, you might have more details there.

Comment 6

[Ellie]

It's slow and I think the bigger problem is it has very unpredictable and varying rates of package loss. I assume pretty close to worst case for hitting the weirdest network code corner cases.

Comment 7

[Ellie]

Okay, so there seem to be two components to this breaking and I set up a test case now.

The first problem is that it breaks at all which seems to be a HTTP/2 implementation problem for which I filed a bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1868987 and the second problem is that the UI just silently eats the error instead of showing any feedback, for which I filed this ticket here.

Check the steps to reproduce of https://bugzilla.mozilla.org/show_bug.cgi?id=1868987 for a test case for both!

Comment 8

[Manuel Bucher [:manuel]]

This sounds similar to Bug 1325876, our error displaying certainly needs to improve. This bug is about improving it in devtools? Improving the shown error page might need a bug in Networking or DOM: Navigation component.

Comment 9

[Ellie]

Both the web page UI and the dev tools UI are affected. The web page doesn't show any indicator of a problem whatsoever, not even a blank page, it just eventually stops showing the "loading"/data transfer hour glass at some point with zero explanation. The dev tools UI as shown in the attached screenshots shows the request, but doesn't properly mark it as failed and as a client-side networking error when it should.

Comment 10

[Manuel Bucher [:manuel]]

True, slightly different from Bug 1325876. I saw a similar behavior in Bug 1781083, where it froze the page with uBlock enabled and just kept displaying the page with uBlock disabled, but that is also a different bug.

Both the web page UI and the dev tools UI are affected.

Since these components are handled by different teams: devtools and Networking (or DOM), it might be good to have a bug for each component, so each team is aware of the bug. To know what exactly needs an error page a network would be helpful for me. Let's track that in 1868987#c2.

Comment 11

[Manuel Bucher [:manuel]]

FYI (from 1868987#c8): the channel with the POST request is cancelled with the error NS_ERROR_ABORT. Due to HTTP/2 ping timeout:

2023-12-11 18:05:37.278965 UTC - [Parent 19692: Socket Thread]: I/nsHttp Http2Session::ReadTimeoutTick 7faf1adf6600 Ping Timer Exhaustion
2023-12-11 18:05:37.278978 UTC - [Parent 19692: Socket Thread]: I/nsHttp Http2Session::Close 7faf1adf6600 804B000E
2023-12-11 18:05:37.279005 UTC - [Parent 19692: Socket Thread]: I/nsHttp MaybeDecrementConcurrent 7faf1adf6600 id=0x13 concurrent=1 active=1
2023-12-11 18:05:37.279021 UTC - [Parent 19692: Socket Thread]: V/nsHttp nsHttpTransaction::Close [this=7faf18abf600 reason=80004004]