Closed Bug 287120 Opened 19 years ago Closed 19 years ago

[FIXr]input type=file inside of an iframe, inside of a div, loses data when the outer divs overflow property is changed.

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: enrique, Assigned: bzbarsky)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

With an input of type file, inside of an iframe, and a div, if the div has it's
overflow style changed, the input field loses it's data.

Reproducible: Always

Steps to Reproduce:
1. See the test case.
2. Click on setIframeContent
3. Click the browse button, and select a file.
3. Click on make overflow visible
4. Watch the file name disappear.

Actual Results:  
The file name dissappeared.

Expected Results:  
The file name should have stayed in the input field.
Attached file Test case
I'm not sure if our content model forces a repainting with the overflow:scroll. 

Confirming:  DOM Inspector shows that the value property of the input is
destroyed.  This suggests that the element itself is destroyed/replaced, and
possibly its owner document (the contentDocument of the iframe) as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing the overflow value causes a layout object reconstruct, which includes
rebuilding the layout objects inside the iframe.  Now for _most_ form controls
we restore the value from the form control's DOM node when this happens, but for
file controls we don't (for security reasons).  Perhaps in this case we should?
Yeah, defenetly. Destruction and reconstruction of layout objects shouldn't
cause the fileinput to loose its value.
We might not want to restore the filecontrol value on 'back' since it could be
bad that a site can regrab a once uploaded file for as long as the page lives in
history. OTOH the site could do that by just reloading the page that was
generated as a result of the submission.

In any case I think that the form-restore code is separate from the problem in
this bug.
So... if the file input is NOT in an iframe, things work fine.  So in general
the code works.

Also of note is that in my testing build I can't reproduce (though I have some
large-scale changes to text inputs in that build, so that may matter here, I
guess....)
And in fact it's something about my lazy-editor changes (which are totally not
ready for prime-time) that makes the bug not show up in my build...
Blocks: 287446
No longer blocks: 287446
Attached patch Proposed fixSplinter Review
Comments describe what's going on here...
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #180733 - Flags: superreview?(jst)
Attachment #180733 - Flags: review?(bugmail)
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Summary: input type=file inside of an iframe, inside of a div, loses data when the outer divs overflow property is changed. → [FIX]input type=file inside of an iframe, inside of a div, loses data when the outer divs overflow property is changed.
Target Milestone: --- → mozilla1.8beta2
Comment on attachment 180733 [details] [diff] [review]
Proposed fix

sr=jst
Attachment #180733 - Flags: superreview?(jst) → superreview+
Summary: [FIX]input type=file inside of an iframe, inside of a div, loses data when the outer divs overflow property is changed. → [FIXr]input type=file inside of an iframe, inside of a div, loses data when the outer divs overflow property is changed.
Comment on attachment 180733 [details] [diff] [review]
Proposed fix

This makes the teardown code for file inputs saving state actually work even if
the whole presentation is coming down... This is pretty safe.
Attachment #180733 - Flags: approval1.8b2?
Comment on attachment 180733 [details] [diff] [review]
Proposed fix

a=brendan for 1.8b2.

/be
Attachment #180733 - Flags: approval1.8b2? → approval1.8b2+
Fixed
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: