Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > cloneNode'ing file input

Reply
Thread Tools

cloneNode'ing file input

 
 
garthb@gmail.com
Guest
Posts: n/a
 
      10-19-2005
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

 
Reply With Quote
 
 
 
 
Jim Ley
Guest
Posts: n/a
 
      10-19-2005
On 19 Oct 2005 13:25:47 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) 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.
 
Reply With Quote
 
 
 
 
garthb@gmail.com
Guest
Posts: n/a
 
      10-19-2005
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)

 
Reply With Quote
 
Jim Ley
Guest
Posts: n/a
 
      10-19-2005
On 19 Oct 2005 13:52:02 -0700, (E-Mail Removed) 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.
 
Reply With Quote
 
Grant Wagner
Guest
Posts: n/a
 
      10-19-2005
On Wed, 19 Oct 2005 20:38:24 GMT, (E-Mail Removed) (Jim Ley) wrote:

> On 19 Oct 2005 13:25:47 -0700, (E-Mail Removed) 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 <(E-Mail Removed)>
comp.lang.javascript FAQ - http://jibbering.com/faq
 
Reply With Quote
 
Jim Ley
Guest
Posts: n/a
 
      10-19-2005
On Wed, 19 Oct 2005 20:58:20 GMT, Grant Wagner <(E-Mail Removed)>
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.
 
Reply With Quote
 
garthb@gmail.com
Guest
Posts: n/a
 
      10-19-2005
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!

 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-19-2005

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?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to restrict user from input in <input type="file"> Tarkeshwar Javascript 2 04-17-2006 11:44 AM
Getting User Input after getting Input from a file dei3cmix@uga.edu C++ 3 03-23-2006 05:01 AM
Which is faster in ASIC: 2-input AND gate or a 2-input multiplexer Weng Tianxiang VHDL 12 08-11-2005 10:50 AM
hide the input box or change the color of input box in html ashutosh Java 3 06-16-2005 02:21 PM
Input Drops With An Empty Input Queue Spiz Cisco 12 05-18-2005 05:28 PM



Advertisments