WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
12273
REGRESSION: File input value invisible after removing and re-appending
https://bugs.webkit.org/show_bug.cgi?id=12273
Summary
REGRESSION: File input value invisible after removing and re-appending
Jeremy Nicoll
Reported
2007-01-14 15:49:33 PST
The current version of Safari does not reset the value of a file input object if it is reassigned to another form object like so: var f = document.getElementById('upload_file_ele'); f.parentNode.removeChild(f); document.getElementById('form2').appendChild(f); However, the latest nightly of WebKit resets the value so that the file input will read "No file selected." This will cause issues for me in the future as I am developing an AJAX script that depends on the behavior of Safari as it currently stands because it monitors the upload of each file individually, and I have to assign each file input to a seperate form object in order to do so. There is a similar behavior which is present in the latest versions of Safari and Webkit which are not present in Firefox or Opera, in which if the cloneNode(true) method is invoked on a file input element then the value is not cloned. This was the first way I tried to solve my before-mentioned problem.
Attachments
scenario 1 as mentioned below
(529 bytes, text/html)
2007-01-15 22:42 PST
,
Darin Adler
no flags
Details
patch with change log
(34.22 KB, patch)
2007-01-15 23:04 PST
,
Darin Adler
aroben
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
David Kilzer (:ddkilzer)
Comment 1
2007-01-14 15:53:45 PST
Jeremy, please attach a stand-alone test case of this issue to this bug. Thanks!
Jeremy Nicoll
Comment 2
2007-01-14 17:44:31 PST
Just to clarify, the desired behavior is that the value of the fine input element NOT be cleared when cloned or moved to another parent. Scenario 1 (works in Safari, not in latest Webkit): <script type="text/javascript"> function press_this () { var f = document.getElementById('upload_1'); f.parentNode.removeChild(f); document.getElementById('form2').appendChild(f); } </script> <form action="test.php" method="POST" enctype="multipart/form-data"> <input type="file" name="upload" id="upload_1"/> </form> <input type="button" onclick="press_this();"/> <form action="test.php" method="POST" id="form2" enctype="multipart/form-data"> </form> --------------------------------------- If you select a file, and then press the button, the selected file is gone in the element. Scenario 2 (works in neither): <script type="text/javascript"> function press_this () { var f = document.getElementById('upload_1'); var f2 = f.cloneNode(true); document.getElementById('form2').appendChild(f2); } </script> <form action="test.php" method="POST" enctype="multipart/form-data"> <input type="file" name="upload" id="upload_1"/> </form> <input type="button" onclick="press_this();"/> <form action="test.php" method="POST" id="form2" enctype="multipart/form-data"> </form> -------------------------------- The selected value is not copied with cloneNode() in either Safari or the Webkit nightly.
Alexey Proskuryakov
Comment 3
2007-01-15 06:44:25 PST
Confirming the first case as a regression (->P1). The second case is somewhat more questionable, since IE 7 also doesn't clone the file input value. It's likely that we will need to discuss it separately, may I ask you to file a new bug for it?
David Kilzer (:ddkilzer)
Comment 4
2007-01-15 09:02:30 PST
(In reply to
comment #3
)
> The second case is somewhat more questionable, since IE 7 also doesn't clone > the file input value. It's likely that we will need to discuss it separately, > may I ask you to file a new bug for it?
See
Bug 12279
.
David Kilzer (:ddkilzer)
Comment 5
2007-01-15 09:03:07 PST
(In reply to
comment #4
)
> (In reply to
comment #3
) > > The second case is somewhat more questionable, since IE 7 also doesn't clone > > the file input value. It's likely that we will need to discuss it separately, > > may I ask you to file a new bug for it? > See
Bug 12279
.
Bah! See
Bug 12285
instead.
Darin Adler
Comment 6
2007-01-15 22:42:27 PST
Created
attachment 12474
[details]
scenario 1 as mentioned below
Darin Adler
Comment 7
2007-01-15 22:43:41 PST
Looking with the DOM inspector shows that the file input value is there after removing and appending. It's just not being displayed. I think if you upload the form you'll see the same thing. So retitling the bug for the actual symptom.
Darin Adler
Comment 8
2007-01-15 23:04:12 PST
Created
attachment 12475
[details]
patch with change log
Darin Adler
Comment 9
2007-01-15 23:11:11 PST
***
Bug 12285
has been marked as a duplicate of this bug. ***
mitz
Comment 10
2007-01-15 23:13:37 PST
Comment on
attachment 12475
[details]
patch with change log Amusing: - * Copyright (C) 2006 Apple Computer, Inc. + * Copyright (C) 2006, 2007 Apple Inc. [...] + * 3. Neither the name of Apple Computer, Inc. ("Apple") nor the names of
Adam Roben (:aroben)
Comment 11
2007-01-15 23:22:35 PST
Comment on
attachment 12475
[details]
patch with change log + private instead, and made a coupld function members const. Typo: "coupld" r=me. Thanks for cleaning this up!
David Kilzer (:ddkilzer)
Comment 12
2007-01-16 03:24:50 PST
Added keyword to make this easier to find.
Jeremy Nicoll
Comment 13
2007-01-16 07:51:07 PST
Thank you for all your hard work!
Sam Weinig
Comment 14
2007-01-22 14:28:17 PST
Is a regression test possible for this patch?
Darin Adler
Comment 15
2007-01-22 16:31:06 PST
(In reply to
comment #14
)
> Is a regression test possible for this patch?
Not without adding something to WebCore and/or DumpRenderTree. For security reasons, you can't set an <input type=file> from JavaScript.
Darin Adler
Comment 16
2007-01-22 17:00:45 PST
Committed revision 19035.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug