1814068 - Network error page on POST shows POST warning on try again (which shows about:neterror as origin) even if no successful network request happened

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[:Gijs (he/him; back Aug 12)]

STR:

1. Open a page with a form that POSTs (e.g. this bugzilla page)
2. Disconnect from the network
3. Submit the form
4. You get a network error page.
5. Reconnect the network
6. press "try again"

ER:
the request just works

AR:
you get a POST warning, and that POST warning shows about:neterror as the domain

This is confusing. If the network was disconnected, the POST can't have succeeded, and there's no point showing a warning.

(I think this needs fixing in the callchain of https://searchfox.org/mozilla-central/rev/8e9b4484408154b80d7ede9e1b035819fda48fd2/docshell/base/nsDocShell.cpp#12457 - AIUI the code here should be able to tell if the DNS lookup for the request failed, and then not show the warning.)

Even if there is a point to showing the warning, it should not indicate about:neterror as the URL, but the URL where the POST is going.

(I think this might need fixing in the prompt collection code but would probably need a triggering principal for the repost or something from docshell to get a better string here, so initially filing this under DOM: Navigation.)

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

nika: Could you take a look and/or set the severity? Thanks!

Comment 2

[Nika Layzell [:nika] (ni? for response)]

The repost warning prompt is started from session history when reloading here: https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/docshell/base/nsDocShell.cpp#12111. The failed channel which has information about why we're reloading should be available on the extant document.

From there it should be possible to detect the type of error. OTTOMH a status of NS_ERROR_UNKNOWN_HOST should correspond to the DNS lookup failing, which could potentially be used to bypass the check (though perhaps we'd want to do some extra tracking to make sure we can't do multiple reloads off of the same error page document).

With regards to what URI is being shown in the prompt, it doesn't seem we pass in anything other than the BC, so the prompt's URI is presumably coming from the check here: https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/toolkit/components/prompts/src/Prompter.sys.mjs#1140. In the case of about:neterror, we're ending up with the neterror principal here, which isn't what we want.

Perhaps the check should be expanded to also check if this.browsingContext.docShell?.failedChannel is non-null, and to pull the result principal from it with Services.scriptSecurityManager.getChannelResultPrincipal(failedChannel) in that case. I think that would ensure the correct URI is appearing in the prompt OTTOMH.