"no element found" in Firefox when $.post reply has no Content-Type

[eldmannen+jquery@…]

Press Ctrl+Shift+K in Mozilla Firefox to bring up the developer console. Don't use F12 in Firebug.

<?php

function main() {
?>
<script src="jquery-1.9.0.js"></script>
<input type="button" id="moo" value="meow">
<script>
$('#moo').on('click', function() {
  $.post('?op=test', { id: '2' });
});
</script>
<?php
}

function meow() {
  header('Content-Type:');
}

switch($_GET['op']) {
  case "test":
    meow();
    break;
  default:
    main();
    break;
}

?>

You will notice the console say "no element found".

[Rick Waldron]

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Additionally, be sure to test against the "jQuery (edge)" version to ensure the issue still exists—you may need to change this to a specific version depending on the test case.

To get you started, use this boilerplate: ​http://jsfiddle.net/FrKyN/ Open the link and click to "Fork" (in the top menu) to begin.

Also, please read: ​http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-final-released/

[dmethvin]

Isn't this the same as what you've been posting on #11489?

Why isn't your server setting a content type? The only time I can think you'd want to leave it out is on a 204 No Content.

You can use $.ajax to override.

[anonymous]

Replying to rwaldron:

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

I cannot create a jsfiddle test case since jsfiddle does not support changing the HTTP response headers.

Replying to dmethvin:

Isn't this the same as what you've been posting on #11489?

Yes, it is but someone there told me to file a new report.

Replying to dmethvin:

Why isn't your server setting a content type? The only time I can think you'd want to leave it out is on a 204 No Content.

Because, I return no content. I only return HTTP status codes such as 200, 201, 202, 204, 401, 403, 404, etc.

[dmethvin]

So do you specify Content-Length: 0 then?

[anonymous]

Replying to dmethvin:

So do you specify Content-Length: 0 then?

PHP (or lighttpd) automatically sets the Content-Length, so in the example code above it gets set to 0.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

[eldmannen+jquery@…]

But I have replied, although replied as 'anonymous'.

[mheck@…]

I see a similar issue with Backbone.js applications running on Rails. When saving an object, my understanding is that the intent of the closed-loop validation capability is that, should Rails-side validation have to modify the object, the resulting modifications are returned in the response to the Backbone front-end (thus keeping everything in sync). However, the typical case is that no modifications were required, and the resulting response is simply 204: No content. In this case, using materials current as of this date for Fedora 18 (Firefox 19.0, Firebug 1.11.2) I observe a "no element found" error in my log-- though I am not certain I get any other ill effects, due to the (peculiar) structure of my particular application.

I'm a bit new at Backbone and Rails, so it's tricky for me to tell if the problem is in Firebug, Firefox, JQuery, or what. I am, however, extremely familiar with Wireshark, and that's how I verified that this is what's going on.

[lsborg]

It also happens with DELETE.

[kuno@…]

Reported to firefox as ​https://bugzilla.mozilla.org/show_bug.cgi?id=884693

[miketaylr]

I just closed the bugzilla bug ​https://bugzilla.mozilla.org/show_bug.cgi?id=884693 as a dupe of ​https://bugzilla.mozilla.org/show_bug.cgi?id=521301... which was referenced in ​http://bugs.jquery.com/ticket/13654 (and that bug was closed as "notabug"). So there's a bug in Gecko... but I don't think there's a bug in jQuery. Nor do I think jQuery can do much in this situation until we fix 521301.

I would suggest closing this ticket as well, as unsatisfying as that is to the bug reporters. :(

[bzbarsky@…]

What jQuery _could_ do in this situation is to tell the browser to not try parsing as XML at all if it knows that the expected response is not XML. Assuming it knows that, of course. If it doesn't, then it can't.

[miketaylr]

(Turns out those aren't exact dupes in Bugzilla, my bad).

[jzelenkov]

I am facing the same issue in Firefox Aurora 26.0a2 (2013-10-24). I tried setting response headers:

• Content-Length: 0
• Status-Code: 204 (No Content)

I also made sure that response body is empty.

Still get "no element found" error in Firefox.

[anonymous]

I am seeing the same issue with responses to GET requests.

All I'm sending is a status code of 204 (no content).

[dmethvin]

Per the lengthy discussion above, this is a Firefox bug, tracked at ​https://bugzilla.mozilla.org/show_bug.cgi?id=521301 .

For more information on why this needs to be fixed by Firefox, see the explanation at ​http://bugs.jquery.com/ticket/13654#comment:14 .