[FIX] Submitting file control that's just been added to the DOM fails

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Layout: Form Controls
P3
normal
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Arpad Ray, Assigned: bz)

Tracking

Trunk
mozilla1.9alpha1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

When cloning a file input (with an existing value) from a form in one document to another (eg. to a form in an iframe), submitting the form using the submit() method causes the file input to lose its value. Its name persists but the filename and data don't.

If the form is submitted manually with a submit button, it works perfectly.

Reproducible: Always

Steps to Reproduce:
1. Enter a file into a file input
2. Use cloneNode to append it to a form in another document
3. call the submit() method on that form, rather than clicking the submit button

Actual Results:  
The element name is sent, but the filename is blank and there's no data.



Expected Results:  
The element should be sent as normal.

Example output: (two form values and the file)
-----------------------------214762178421665
Content-Disposition: form-data; name="aupload_file_id"

d41d8cd98f00b204e9800998ecf8427e
-----------------------------214762178421665
Content-Disposition: form-data; name="aupload_file_name"


-----------------------------214762178421665
Content-Disposition: form-data; name="myfile"; filename=""
Content-Type: application/octet-stream


-----------------------------214762178421665--
Created attachment 209331 [details] [diff] [review]
Patch

So the actual issue here (based on debugging Arpad's testcase) is that we're submitting before initial reflow of the file control frame, and that can't get the value off the mTextFrame until it sets it... in initial reflow.  The cross-document thing and the cloneNode thing are incidental -- you could get the same effect with some style toggling on a single file input in the DOM.
Assignee: nobody → bzbarsky
Status: UNCONFIRMED → ASSIGNED
Attachment #209331 - Flags: superreview?(roc)
Attachment #209331 - Flags: review?(roc)
roc, I realize that for 1.9 we'll try to nix the whole textfield thing, but I think this might be a good change for 1.8.1 too...
OS: Windows XP → All
Priority: -- → P3
Hardware: PC → All
Summary: cloneNode(file input) between documents loses value on submit() → [FIX] Submitting file control that's just been added to the DOM fails
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 209331 [details] [diff] [review]
Patch

I agree with your XXX comment. Seems like textControl.value should always work.
Attachment #209331 - Flags: superreview?(roc)
Attachment #209331 - Flags: superreview+
Attachment #209331 - Flags: review?(roc)
Attachment #209331 - Flags: review+
Created attachment 210624 [details] [diff] [review]
What I checked in

I made this always use mTextControl.
Attachment #209331 - Attachment is obsolete: true
Er, I meant mTextContent.  In any case, fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.