#372 bug

IE writeAttribute() type not allowed

Reported by Xanadu | October 6th, 2008 @ 02:50 PM | in After 1.7

IE prohibits the change of the 'type' attribute.

<input id="check" type="checkbox" />

$('check').writeAttribute('type', 'hidden'); // FAILS
$('check').writeAttribute('type', 'checkbox'); // Doesn't change it and will not fail.

The solution I am thinking of is replacing the element with a new one having its type set.

Comments and changes to this ticket

  • Andrew Dupont

    Andrew Dupont October 6th, 2008 @ 04:43 PM

    • State changed from “new” to “bug”
    • Tag set to attributes, discuss, ie

    We've considered this before, but I worry that this may be too "radical" of a fix for us to attempt. Do others have thoughts?

  • Xanadu

    Xanadu October 7th, 2008 @ 02:07 AM

    I tried to create a fix myself, googled some and prototype-ified it a little.

      writeAttribute2: function(element, name, value) {
     /* regular writeAttribute code here... */
          else if (Prototype.Browser.IE && ['name','type'].indexOf(name) > -1)
    		element._setAttributeIE(name, value);
          else element.setAttribute(name, value);
        return element;
    	_setAttributeIE : function (element, name, value)
    	    element = $(element);
    		var attributes = element.attributes;
    		var newElement = document.createElement(element.tagName);
    		newElement[name] = value;
    		for (attr in attributes)
    			if (attr != name && attributes[attr] && attributes[attr] != '')
    				newElement.setAttribute(attr, attributes[attr]);
    		element.insert({after : newElement});
    		return newElement;

    Not the best thing, still buggy and probably not very fast.

    Maybe something like this would be better

  • Xanadu

    Xanadu October 13th, 2008 @ 02:31 PM

    It might be 'radical', but in my opinion it is something that a framework could fix.

    More opinions are welcome...

  • Juriy Zaytsev

    Juriy Zaytsev October 14th, 2008 @ 07:06 PM

    I'm afraid replacing element is a bit too obtrusive. What if there are event handlers attached to it?

  • Xanadu

    Xanadu October 14th, 2008 @ 11:51 PM

    Hmm, didn't even think of that. Other downside, if you want to change both name and type, it would be creating a new element twice.

    I am thinking: it is possible to remove the 'type' attribute? Obviously the attribute needs to added again with the new value.

  • Xanadu

    Xanadu October 15th, 2008 @ 12:11 AM

    A little test.

    <input type="checkbox" value="1" name="checkbox" id="checkbox" />
    <script type="text/javascript">
    var c = $('checkbox');
    c.setAttribute('type', 'text');

    Echoes 'null' and 'text' in Opera. Since I see no bug reports and no alert I am assuming it fails.

  • Xanadu

    Xanadu October 15th, 2008 @ 12:18 AM

    IE7 alerts 'checkbox'... I am sorry.

    With seeing no bug reported I ment in IE of course!

  • Xanadu

    Xanadu October 15th, 2008 @ 12:30 AM

    Came up with new nifty function, appears to work in IE7 and IE6.

    var c = Element.wrap($('checkbox'), 'div', { 'class': 'checkboxDiv' });
    c.innerHTML = c.innerHTML.replace('type=checkbox', 'type=text');
    c.setAttribute('type', 'text');

    Needs some work (removing the wrapper for example :P), but it's my most successful try so far.

    It removes the 'type' for a short period of time, when not changing to the default value 'text' it would propably show a text input before changing to the wanted type.

  • Xanadu

    Xanadu October 15th, 2008 @ 12:37 AM

    changing the value in c.setAttribute('type', 'text'); causes the following alert to print the value provided. This is an essential part.

    (Offtopic question: Why can't I edit a comment?)

  • Tobie Langel

    Tobie Langel October 15th, 2008 @ 10:37 AM

    Changing innerHTML will loose handlers just as much as cloning the element would. So that's not a solution either.

    I'd like to add that their are (imho) justified security reasons to prevent modifying the type of input elements. For example, if you where allowed to modify the type of a file input into a text input before submitting the form, you could potentially override the user's choice and upload a different file than the one he selected.

  • Xanadu

    Xanadu October 16th, 2008 @ 01:45 AM

    If a file input is converted to a text field, it wouldn't upload the file. That would just post a string to the server. Converting it to a file input is what would security issues.

    The same restriction appears to be on the name-attribute. I don't see why from a security point of view.

    My first solution is probably the 'best', if there is a way to reattach event handlers. I wonder if and how that can be done (using the on...-properties?).

    If reattaching event handlers is possible, I think the documentation should state that when changing both type and name (and other read-only attributes I missed) it is best to call writeAttribute using a hash.

  • Juriy Zaytsev

    Juriy Zaytsev October 16th, 2008 @ 04:01 AM


    I don't think changing type of an input element could be a security concern. Besides the fact that every major browser (except IE) allows it, sending file contents of a text input element just because it was once a type="file" element would seem like a serious implementation flaw.

    Besides, specs (although being usually vague) seem to mention that files associated with file select controls are submitted upon submission of a form. http://www.w3.org/TR/html401/int....13.2

  • Tobie Langel

    Tobie Langel October 16th, 2008 @ 07:44 AM

    I obviously meant to say:

    For example, if you where allowed to modify the type of a text input into a file input before submitting the form, you could potentially override the user's choice and upload a different file than the one he selected.

    Having a third party script steal a password is another possible attack vector stopped by preventing input type changes.

    I'm not saying this is a good or bad thing. I'm just pretty certain these where motivated by security issues initially.

  • Xanadu

    Xanadu October 20th, 2008 @ 12:39 AM

    Setting the value of a file input appears to be impossible in Opera and Firefox. When changing a the type of an input from 'text' to 'file' input it removes the value. Obviously done to prevent uploading files the user did not select himself.

    <input type="text" id="textinput" /><br />
    <input type="file" id="fileinput" /><br />
    <input type="file" id="fileinput2" />
    <script type="text/javascript">
    $('textinput').setAttribute('value', 'C:\\test.txt'); // Just to confirm the value is altered...
    $('fileinput').setAttribute('value', 'C:\\test.txt'); // Silently fails
    fileinput2 = $('fileinput2');
    fileinput2.setAttribute('type', 'text');
    fileinput2.setAttribute('value', 'C:\\test.txt'); // Value set!
    fileinput2.setAttribute('type', 'file'); // Value unset!
  • Robert Kieffer (broofa)

    Robert Kieffer (broofa) February 17th, 2009 @ 09:32 PM

    My $.02: Changing the type of an element is conceptually a pretty drastic operation. An element's is really tantamount to it's "class" (OO class, not CSS class). It defines the nature of the element - how it behaves, what it looks like, what you can do with it - in ways that no other attribute does. (Compare the impact a change in type has to what a change in width, height, or pretty much any other attribute has.)

    Thus, I don't see this as a bug... at least not one that Prototype should attempt to fix. This is not something that a significant portion of Prototype developers are going to want/need and so any code that is added to fix this is unlikely to contribute to the effective value the library offers and will, instead, just be so much code bloat. (imho).

  • Tobie Langel

    Tobie Langel February 17th, 2009 @ 11:11 PM

    • Milestone set to 1.7
    • Assigned user set to “Tobie Langel”

    jQuery handles this by forbidding changing the type altogether. It might be the best solution, after all.

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:39 AM

    • Tag changed from attributes, discuss, ie to ie, needs:discussion

    [not-tagged:"discuss" tagged:"needs:discussion" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 04:05 AM

    • Tag changed from ie, needs:discussion to needs:discussion

    [not-tagged:"ie" not-tagged:"ie6" not-tagged:"ie7" not-tagged:"ie8" bulk edit command]

  • T.J. Crowder

    T.J. Crowder November 16th, 2009 @ 04:50 PM

    • Assigned user cleared.

    [responsible:none bulk edit command]

  • Tisho Georgiev

    Tisho Georgiev March 1st, 2010 @ 09:55 PM

    • Tag changed from needs:discussion to needs:discussion, section:dom
  • Andrew Dupont

    Andrew Dupont October 17th, 2010 @ 08:12 AM

    • Milestone changed from 1.7 to After 1.7
    • Assigned user set to “Andrew Dupont”
    • Importance changed from “” to “Low”

    Moving this to after 1.7 because of its low priority. But I am in favor of following jQuery's lead.

  • Jason Westbrook
  • chenlina1
  • xtream bee

    xtream bee October 4th, 2018 @ 08:05 PM

    hey. This post couldn't be written a ways that better! learning this post rings a bell in my memory of my previous house partner. He invariably placed chatting regarding this. i will be able to forwards this information processing system to him. really sure he's attending to have a extremely smart study. thanks for sharing.
    ISL 2018 2019 ISl Live Stream ISL Points Table

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

The Prototype JavaScript library.

Shared Ticket Bins