cloneNode'ing file input

Discussion in 'Javascript' started by garthb@gmail.com, Oct 19, 2005.

  1. Guest

    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
     
    , Oct 19, 2005
    #1
    1. Advertising

  2. Jim Ley Guest

    On 19 Oct 2005 13:25:47 -0700, 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.
     
    Jim Ley, Oct 19, 2005
    #2
    1. Advertising

  3. Guest

    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)
     
    , Oct 19, 2005
    #3
  4. Jim Ley Guest

    On 19 Oct 2005 13:52:02 -0700, 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.
     
    Jim Ley, Oct 19, 2005
    #4
  5. Grant Wagner Guest

    On Wed, 19 Oct 2005 20:38:24 GMT, (Jim Ley) wrote:

    > On 19 Oct 2005 13:25:47 -0700, 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 <>
    comp.lang.javascript FAQ - http://jibbering.com/faq
     
    Grant Wagner, Oct 19, 2005
    #5
  6. Jim Ley Guest

    On Wed, 19 Oct 2005 20:58:20 GMT, 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 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.
     
    Jim Ley, Oct 19, 2005
    #6
  7. Guest

    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!
     
    , Oct 19, 2005
    #7
  8. VK Guest

    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?
     
    VK, Oct 19, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?TW9ua2V5Qm95?=
    Replies:
    2
    Views:
    447
    =?Utf-8?B?TW9ua2V5Qm95?=
    Jun 6, 2004
  2. Sullivan WxPyQtKinter
    Replies:
    0
    Views:
    1,962
    Sullivan WxPyQtKinter
    Mar 14, 2006
  3. Chameleon

    appendChild & cloneNode

    Chameleon, Jun 1, 2009, in forum: XML
    Replies:
    25
    Views:
    3,783
    Thomas 'PointedEars' Lahn
    Jun 3, 2009
  4. itsme

    XmlDocument and cloneNode

    itsme, Oct 14, 2003, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    151
    itsme
    Oct 14, 2003
  5. chippy
    Replies:
    4
    Views:
    148
    chippy
    Jan 4, 2006
Loading...

Share This Page