Bug 12273 - REGRESSION: File input value invisible after removing and re-appending
Summary: REGRESSION: File input value invisible after removing and re-appending
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Major
Assignee: Darin Adler
URL:
Keywords: HasReduction, Regression
: 12285 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-01-14 15:49 PST by Jeremy Nicoll
Modified: 2007-01-22 17:00 PST (History)
1 user (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Nicoll 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.
Comment 1 David Kilzer (:ddkilzer) 2007-01-14 15:53:45 PST
Jeremy, please attach a stand-alone test case of this issue to this bug.  Thanks!

Comment 2 Jeremy Nicoll 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.
Comment 3 Alexey Proskuryakov 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?
Comment 4 David Kilzer (:ddkilzer) 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.

Comment 5 David Kilzer (:ddkilzer) 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.
Comment 6 Darin Adler 2007-01-15 22:42:27 PST
Created attachment 12474 [details]
scenario 1 as mentioned below
Comment 7 Darin Adler 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.
Comment 8 Darin Adler 2007-01-15 23:04:12 PST
Created attachment 12475 [details]
patch with change log
Comment 9 Darin Adler 2007-01-15 23:11:11 PST
*** Bug 12285 has been marked as a duplicate of this bug. ***
Comment 10 mitz 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
Comment 11 Adam Roben (:aroben) 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!
Comment 12 David Kilzer (:ddkilzer) 2007-01-16 03:24:50 PST
Added keyword to make this easier to find.

Comment 13 Jeremy Nicoll 2007-01-16 07:51:07 PST
Thank you for all your hard work!
Comment 14 Sam Weinig 2007-01-22 14:28:17 PST
Is a regression test possible for this patch?
Comment 15 Darin Adler 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.
Comment 16 Darin Adler 2007-01-22 17:00:45 PST
Committed revision 19035.