.attr can't change a submit input

[remysharp]

Changing a submit input element to a button (or perhaps another type) causes jQuery to throw a fatal exception:

$('input[type=submit]').attr('type', 'button'); // throws fatal

Working example: ​http://jsbin.com/arida/2

Note that it throws an exception (which is why I've wrapped them in a try/catch for the example).

Broken in: Chrome 9, Firefox 3.6.x, Safari 5 (not, as jitter had, just IE).

[jitter]

Thanks for taking the time to contribute to the jQuery project by writing a bug report and providing a test case!

This is a bug in Internet Explorer that can't be worked around (IE doesn't allow the type attribute to be changed). There is a note about this on ​http://api.jquery.com/jQuery/ . I notified the api documentation team to add this missing hint to the .attr() api page too.

[jitter]

#8231 is a duplicate of this ticket.

[Adrian Mester <mesteradrian@…>]

Actually this also seems to also happen in Chrome (9.0.597.84 beta) and Firefox (3.6.13). Changing a submit button's type attribute nodeValue to button (ie without using jQuery), works in these browsers. So I think this is a bug in jQuery

[jitter]

Replying to Adrian Mester <mesteradrian@…>:

Actually this also seems to also happen in Chrome (9.0.597.84 beta) and Firefox (3.6.13). Changing a submit button's type attribute nodeValue to button (ie without using jQuery), works in these browsers. So I think this is a bug in jQuery

Yes this happens in every browser and purposefully so. #1536 and ​7d02f06e

[remysharp]

Replying to jitter:

Thanks for taking the time to contribute to the jQuery project by writing a bug report and providing a test case!

This is a bug in Internet Explorer that can't be worked around (IE doesn't allow the type attribute to be changed). There is a note about this on ​http://api.jquery.com/jQuery/ . I notified the api documentation team to add this missing hint to the .attr() api page too.

Erm...I didn't test IE. It's happening in Chrome 9, Safari 5 and Firefox 3.6.x. I assume the test case wasn't even opened then?

[jitter]

Replying to remysharp:

Erm...I didn't test IE. It's happening in Chrome 9, Safari 5 and Firefox 3.6.x. I assume the test case wasn't even opened then?

Umm.. wtf of course I opened the test case - and no not with IE - after reading the report, I also checked the source. So, yes I saw the exception in a non IE browser (but also knew there would be one without checking).

My answer stands as it is! Did you read my ​comment and the links there??

Yes this happens in every browser and purposefully so. #1536 and ​7d02f06e

Let me ​quote John directly

Attempting to do this now throws an exception in all browsers

So this behavior isn't a bug. The error is thrown on purpose, because this is something that can't be worked around in IE. So we disallow it for all browsers because else people do this and then wonder why it doesn't work in IE.

[Rick Waldron]

@remysharp As I know you are a very capable JavaScript programmer, I'm going to close this as "patchwelcome". John's own commit message and Anton(jitter)'s thorough research supports this behaviour as being valid - but we welcome you to solve the issue.

[paul.irish]

I'm pretty sure there's a miscommunication here.

Changing the input type with jQuery will throw an exception, due to ​7d02f06e

But changing the input type in JavaScript generally does not throw an exception, except in IE.

There are plenty of instances in which jQuery is used without concern for IE. So perhaps jQuery shouldn't amputate attr()s functionality for all browsers..

[Rick Waldron]

@paul.irish As the closing status says "patchwelcome"

[dmethvin]

Removing the thrown error doesn't fix Remy's code in the video here, where he calls this a "bug in jQuery" but certainly he must not have intended to create code that IE won't run:

​http://jqueryfordesigners.com/video.php?f=select-boxes.mp4

Even if we remove the thrown error, the code will seem to work just peachy when tested in webkit/firefox and then bite everyone who doesn't test in IE and/or doesn't understand the underlying issue.

The reason this was put in originally was because people wanted jQuery to be "cross-browser" and behave consistently with respect to this problem. If we revert the behavior so that it tries to set the type of the button, it *will* die in IE. The code to totally work around the problem in IE -- create a new element, copy over attributes, data and events, replace the old element -- is not worth it IMO. But the ticket says patchwelcome; maybe someone can come up with a small, fast, well-tested fix.

I am also totally OK with reverting this check and letting IE alone die, but we've gone back and forth on it for five years. If everyone in the room now will make a blood pact that this is really the right thing to do and we shall never again speak of it, we could set #1536 (that patched it three years ago to generate an error), #5544, #1957, #1359, and #120 (me five years ago!) to wontfix and let the world fend for itself on IE. I think it will still continue to create tickets either way.

[remysharp]

Okay, misunderstood @jitters test - I see what we're dealing with now. Let us put our handbangs back down and chill :)

Honestly, it feels pretty weird that jQuery is replicating a bug in IE, but I can understand there's been more than a quick pint and chat about that decision.

The way I see it, is there's two good ways to approach this rather specific, but obtuse bug:

1. a touch more detail in the exception description ("the type cannot be changed" - I just figured it was the usual crap that IE errors throw "there was an error in the script", etc) - or at least a link pointing to /why/ it's like that (not just to the .attr api docs, at least to an anchor point in the page).

2. As Dave suggested, clone the element and replace it. I don't see this as a terrible idea, it certainly fixes an age old issue in IE, rather than replicating one.

Either way, Rick's marked it as #patchwelcome, so it's all fair game.

Cheers.

• Remy.

[dmethvin]

#8329 is a duplicate of this ticket.