Revert [22611] in favor of using plupload's container setting. Turns out, plupload's flash shim is forced to the exact same index as the admin bar, so balancing the two is better solved by nesting the shim.

I forgot about this. Older versions of IE don't like application/json and should instead receive text/plain (I think, over text/html). Not sure if there are workarounds beyond browser detection or always serving text/*.

I seem to recall there being an explicit JS-based, koop-ordered reason for delivering application/json instead of text/html here. He will know if text/plain would be okay instead.

We're using application/json so jQuery's ajax method automatically parses the JSON. It also accepts text/javascript, which sounds like a viable IE fallback. I'd like to see a patch that sniffs for IE and replies with text/javascript instead.

If that doesn't work, we can overload it client-side to make sure that takes place, but then our shiny new ajax functions lose a bit of their luster.

The fact that all of the other XHR requests are performing correctly means that jQuery is handling the current code correctly — the error here is with plupload. And understandably so, as it is juggling numerous transports.

Instead of using the new wp_send_json_* methods (which we already had to manually parse), we should just use the traditional method of echoing some json and calling wp_die() in wp_ajax_upload_attachment().

Don't use wp_send_json_* handlers in the upload-attachment XHR handler.

The difference is the content type: application/json (which jQuery deserializes automatically for us) and the default text/html.

jQuery correctly handles application/json requests for IE, so we can continue to use the wp_send_json_* handlers elsewhere. Plupload rolls its own requests and does not handle application/json correctly. So, keep the standard text/html content type on upload-attachment.