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.

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.

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

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.

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.

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).