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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: enrique, Assigned: bzbarsky)
Details
Attachments
(2 files)
1.69 KB,
text/html
|
Details | |
1.52 KB,
patch
|
sicking
:
review+
jst
:
superreview+
brendan
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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.
Comment 2•19 years ago
|
||
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
Assignee | ||
Comment 3•19 years ago
|
||
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.
Assignee | ||
Comment 6•19 years ago
|
||
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....)
Assignee | ||
Comment 7•19 years ago
|
||
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...
Assignee | ||
Comment 8•19 years ago
|
||
Comments describe what's going on here...
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #180733 -
Flags: superreview?(jst)
Attachment #180733 -
Flags: review?(bugmail)
Assignee | ||
Updated•19 years ago
|
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
Attachment #180733 -
Flags: review?(bugmail) → review+
Comment 9•19 years ago
|
||
Comment on attachment 180733 [details] [diff] [review] Proposed fix sr=jst
Attachment #180733 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Updated•19 years ago
|
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.
Assignee | ||
Comment 10•19 years ago
|
||
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 11•19 years ago
|
||
Comment on attachment 180733 [details] [diff] [review] Proposed fix a=brendan for 1.8b2. /be
Attachment #180733 -
Flags: approval1.8b2? → approval1.8b2+
Assignee | ||
Comment 12•19 years ago
|
||
Fixed
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•