cloneNode'ing file input

[garthb]

Hello,

In Mozilla (Firefox 1.0.7) I can cloneNode a file input element that
has a selected file value and appendChild it to another form without a
problem.

IE 6 loses the selected file value. Is this a bug with IE that it
loses the value, or with FF that it keeps it?

I'd really like to be able to maintain the selected file value in IE.

Does anyone have any advice or experience with cloneNode that can
provide some insight?

I have not tried this on any browsers other than IE 6 and FF 1.0.7.

Thank you,
Garth

[Jim Ley]

On 19 Oct 2005 13:25:47 -0700, ga****@gmail.com wrote:

In Mozilla (Firefox 1.0.7) I can cloneNode a file input element that
has a selected file value and appendChild it to another form without a
problem.

IE 6 loses the selected file value. Is this a bug with IE that it
loses the value, or with FF that it keeps it?

I don't think either could truly be considered a bug, but I'm afraid
you'll just have to live with IE's behaviour.

Jim.

[garthb]

Thank you Jim for the honest if somewhat disheartening response.

All of this is an attempt to submit one or more files without
disturbing the page that the file inputs are sitting on. The rest of
the form data is submitted using the xmlhttprequest object via post.

If I can send these files using "ajax" style techniques that would
solve my problem entirely, but I haven't found a way to do that. I
also haven't found anyone else who has done it either, so I'm still
assuming that it can't be done.

Anyone have anything further to offer before I move on to a different
approach? (darn IE)

[Jim Ley]

On 19 Oct 2005 13:52:02 -0700, ga****@gmail.com wrote:

If I can send these files using "ajax" style techniques that would
solve my problem entirely, but I haven't found a way to do that. I
also haven't found anyone else who has done it either, so I'm still
assuming that it can't be done.

Oh no, that's easy, just give your form a target of an IFRAME with the
name you want, then the submission goes to the IFRAME, the main
document isn't disturbed and you use normal cross frame scripting to
get the results back.

People have been doing it for years, long before ajax have ceased to
be just another mediocre european football team...

Jim.

[Grant Wagner]

On Wed, 19 Oct 2005 20:38:24 GMT, ji*@jibbering.com (Jim Ley) wrote:

On 19 Oct 2005 13:25:47 -0700, ga****@gmail.com wrote:

In Mozilla (Firefox 1.0.7) I can cloneNode a file input element that
has a selected file value and appendChild it to another form without a
problem.

IE 6 loses the selected file value. Is this a bug with IE that it
loses the value, or with FF that it keeps it?

I don't think either could truly be considered a bug, but I'm afraid
you'll just have to live with IE's behaviour.

Jim.

I'd consider Firefox's behaviour to be (slightly) less secure than
IE's behaviour. After all, is the value of a file input on one form
really applicable to a file input cloned and placed on another form?

In a browser that doesn't allow linking to file:/// links from the
local hard disk when the page is loaded from http://, retaining the
value of a cloned file input seems odd, out-of-place and unintended to
me. So IE's behaviour seems the "more correct" of the two to me.

I'm sure an equally weak argument could be made as to why it is okay
and proper to retain the value of a cloned file input.

--
Grant Wagner <sq*******@yahoo.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

[Jim Ley]

On Wed, 19 Oct 2005 20:58:20 GMT, Grant Wagner <sq*******@yahoo.com>
wrote:

I'd consider Firefox's behaviour to be (slightly) less secure than
IE's behaviour. After all, is the value of a file input on one form
really applicable to a file input cloned and placed on another form?

In a browser that doesn't allow linking to file:/// links from the
local hard disk when the page is loaded from http://, retaining the
value of a cloned file input seems odd, out-of-place and unintended to
me. So IE's behaviour seems the "more correct" of the two to me.

I'm sure an equally weak argument could be made as to why it is okay
and proper to retain the value of a cloned file input.

I couldn't come up with a scenario whereby cloning an input into
another form would not be equivalent to just changing the action on
the form that contained it originally, but there may well be.

I would lean towards IE too being the one I'd prefer, but can't come
up with a concrete reason why. It might be interesting to see what
Opera does here as it did (does?) let you specify a default value -
prompting the user to confirm the submissoin if the user doesn't
change it.

Cheers,

Jim.

[garthb]

I actually already have an iframe in place which served as the target
for the dynamically created form which I had the cloned file inputs
appendChilded to.

I'll switch around the machinery and just have the original form be
submitted to the iframe. I had a good reason not to submit the
original form, but in the fervor of trying to get the file inputs to be
cloned "properly" I've forgotten why.

Thanks to everyone who has contributed!

[VK]

Grant Wagner wrote:

I'd consider Firefox's behaviour to be (slightly) less secure than
IE's behaviour. After all, is the value of a file input on one form
really applicable to a file input cloned and placed on another form?

In a browser that doesn't allow linking to file:/// links from the
local hard disk when the page is loaded from http://, retaining the
value of a cloned file input seems odd, out-of-place and unintended to
me. So IE's behaviour seems the "more correct" of the two to me.

I'm sure an equally weak argument could be made as to why it is okay
and proper to retain the value of a cloned file input.

I have big eye on both of them (FF and IE). Since beginning of times
you either couldn't get fileInput.value at all using script or
(starting 4th) *only file name w/o path*. Now both are glad to tell me
the full path including drive name even for server-loaded pages. Tested
on IE6 SP1 and FF1.0.7

What a hey (to say the softest) is going on?