Many different things happen here, so I will answer them one at a time.
Chrome and Safari are based on WebKit, so you see the same behavior in these browsers (Chrome will switch to Blink soon, but this is not yet in the hands of users).
The latest CORS specification states that Accept is a simple request header. Origin not on the list of simple request headers, but it would be foolish if it were not supported, as it is the core of CORS. So technically, Firefox is doing it right.
However, note that although Chrome / Safari contains Accept and Origin headers, they do not verify that these headers are included in the Access-Control-Allow-Headers response header. You can check this by visiting the following link:
http://client.cors-api.appspot.com/client#?client_method=PUT&client_credentials=false&client_headers=Accept%3A%20%2A%2F%2A&server_enable=true&server_status=200&server_credentials=fer&erver_server&server_credentals_fer&erver_server
Note that the pre-validation request has the header Access-Control-Request-Headers: accept, origin , but the response does not have Access-Control-Allow-Headers . And the actual CORS request still succeeds.
The Content-Type header is considered a simple request header only when its value is one of the following: application/x-www-form-urlencoded , multipart/form-data or text/plain . All other values will trigger a preflight check. This is probably what you see here.
I have no idea why browsers behave this way. It might be something interesting on WebKit or Firefox message boards. Here is the code where WebKit sets the Access-Control-Request-Headers header:
https://trac.webkit.org/browser/trunk/Source/WebCore/loader/CrossOriginAccessControl.cpp?order=name#L117
It seems that all the headers are listed without removing the simple headers. I assume that on the response side there is code that expects only complicated headers in the Access-Control-Allow-Headers response.