User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Steps to reproduce: This is a bit complicated to reproduce because it requires the use of two different domains and a 302 redirect. It also needs to be on port 80 as I can't get it to reproduce on a non-default port. I'm attaching a Python script that acts as an HTTP server to try to make setting up a reproducer a bit easier. The basic idea is that if a page is on a domain that is whitelisted for file:// access then a form submitted from that page will use a GET request instead of a POST request but only if the page was initially loaded via a 302 redirect from a different domain. 1) Add the following to your /etc/hosts file (or %SYSTEMROOT%\System32\Drivers\etc\hosts on Windows): 127.0.0.1 example.net 127.0.0.1 example.com 2) Create the following preferences in about:config (see http://kb.mozillazine.org/Links_to_local_pages_don%27t_work#Firefox_1.5.2C_SeaMonkey_1.0_and_newer): capability.policy.policynames = "localfilelinks" capability.policy.localfilelinks.checkloaduri.enabled = "allAccess" capability.policy.localfilelinks.sites = "http://example.com" 3) Run the attached Python script to start an HTTP server on 127.0.0.1:80 4) Visit http://example.net/ in a new tab 5) You will be immediately 302 redirected to http://example.com/ 6) Click the submit button Actual results: The browser performs a GET request to http://example.com/form and you see the text "GET /form is BAD". Expected results: A POST request to http://example.com/form should have been performed instead and you would have then seen "POST /form is GOOD". Note that this works as expected (a POST request is sent) if you visit http://example.com/ directly and do not go through the redirect from http://example.net/. If you are on the "GET /form is BAD" page and click Back and then click the submit button again a POST request is performed as expected. Bisecting with mozregression-gui shows that the last known good build is: app_name: firefox build_date: 2017-07-19 build_type: nightly build_url: https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-19-03-02-06-mozilla-central/firefox-56.0a1.en-US.win32.zip changeset: 1b065ffd8a535a0ad4c39a912af18e948e6a42c1 pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1b065ffd8a535a0ad4c39a912af18e948e6a42c1&tochange=0985725c848ec0cfc6f2f3c3a5aa3d71321e7620 repo_name: mozilla-central repo_url: https://hg.mozilla.org/mozilla-central The first known bad build is: app_name: firefox build_date: 2017-07-20 build_type: nightly build_url: https://archive.mozilla.org/pub/firefox/nightly/2017/07/2017-07-20-03-02-03-mozilla-central/firefox-56.0a1.en-US.win32.zip changeset: 0985725c848ec0cfc6f2f3c3a5aa3d71321e7620 pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd1b6a4e5d8e1184a89ae60a74fd86d3d4a9e95c&tochange=0985725c848ec0cfc6f2f3c3a5aa3d71321e7620 repo_name: mozilla-central repo_url: https://hg.mozilla.org/mozilla-central Looking at that pushlog, the changes for Bug 1378377 seem like the most obvious candidate.

Possible regression of bug 1378377?

Hi James, Thanks for taking the time to report this issue in such detail, it really helped reproducing it, specially since its such a technical one. I managed to reproduce this issue in all versions of Firefox including the latest Version of Nightly 65.0a1 (2018-10-24). I am unsure if Networking is the correct component for this issue but it seems like a good place to start, please feel free to change it to a more suitable one.

In order for http://example.com/ to have file:// access, we have to run it in a file content process. That doesn't seem to be happening on redirect and so the POST causes a process switch and fails (which is a known problem when we process switch on POST). Nika - it's been a long time since I've looked through the navigation code, do you know why the redirect isn't going through the process type selection code? On a separate note, perhaps we should block normal http pages from redirecting to ones with whitelisted file:// access.

(In reply to Bob Owen (:bobowen) from comment #3) > In order for http://example.com/ to have file:// access, we have to run it > in a file content process. > > That doesn't seem to be happening on redirect and so the POST causes a > process switch and fails (which is a known problem when we process switch on > POST). > > Nika - it's been a long time since I've looked through the navigation code, > do you know why the redirect isn't going through the process type selection > code? > > On a separate note, perhaps we should block normal http pages from > redirecting to ones with whitelisted file:// access. This should be fixed after I do the POST load changes in bug 1467223. In effect, we currently never re-check process allocation during a load's redirect chain, we only check the original URI. This will be changing soon after we move process allocation checks for http URIs to the parent process at the end of the redirection change in that bug. This should also unbork POST loads :-).