218835 - display:none on iframe causes forms within no to be submitted when using click() method on button.

Status: RESOLVED DUPLICATE of bug 100533

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

Description

[Ian]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

Form submittion fails to occur when attempting to have the parent frame tell a
child frame (which was hiddend using display:none) containing a form to submit
the form using the click() method one of the buttons within that form.

Reproducible: Always

Steps to Reproduce:
See attachements to follow
Actual Results:  
If the child frame is hidden then only the main form will be submitted however
if the child frame is visible using display:block then the inner frame is
submitted and then the main frame. (This is explanation is based on the
attachements to follow.)

Expected Results:  
I would expect that even if the frame is hidden the form would still be
submitted properly.

Comment 1

[Ian]

Attachment: This is the inner frame that will be used for the test. The really test case will be in the next attachement.

Comment 2

[Ian]

Attachment: Testcase

Hope this work - I will be linking to the previous attachement....

NOTE: In this attachment if you click on the unhide repeatably it is switching
the "display" from "none" to "block" and from "block" to "none". Initially when
it is set to none there is not much space between the submit button and the
text below it however when you switch it from "none" to "block" and then back
to "none" it does not go back to the way it was before. I have found a few bugs
related to this but I did not find the one that dupplicates this behaviour -
should you know the bug that this is related to could you let me know.

Comment 3

[Dom Leonard]

whilst the parent frame test page is more complex, this looks like a duplicate
of bug 100533

Comment 4

[Ian]

Yes A agree seems to be the same as bug# 100533

*** This bug has been marked as a duplicate of 100533 ***