User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Steps to reproduce:

Firefox version: 65.0.2 (64-bit
Firefox build id: 20190225143501
Firefox user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Load a web application through https that is not hosted on localhost or 127.0.0.1. (something like https://my-app.com)
Make an XMLHttpRequest towards http://127.0.0.1 using the POST HTTP verb/method where a local app is listening and configured to allow cross origin requests.

Actual results:

Fireofx did not make a CORS preflight request
Firefox failed the request with a CORS policy error

Expected results:

Ideally (as Chrome and Edge do) Firefox should make a preflight request and if the response and the request to be issued are compatible, perform the XMLHttpRequest.

Additionally, I would like to note:

• the error does not occur if the web app from which the request is made is hosted on http
• the error does not occur if the request is a "simple" one. For example requests with the "GET" verb work even from the above mentioned "mixed content" scenario as long as no special headers or anything like that is added to the request. Although the actual request works, the preflight request is still not performed.

Just to clarify the steps to reproduce from above, when I said "Make an XMLHttpRequest towards http://127.0.0.1 using the POST HTTP verb/method", I meant to do so from the context of the previously loaded app (the one loaded through https).

Please provide a testcase.

Hi Matthias, I've created a bug reproduction here: https://github.com/cristi-badila/firefox-bug. I might have been a bit eager in saying that any POST request doesn't work. It seems only "non-simple" requests don't work. A simple one did work however when I added an "Authentication" header to the request as in the bug reproduction code, the request failed as described initially.

This does seem as a duplicate after bug 1376310, but I'm reluctant to mark it so until further confirmation.