In the to be attached testcase, the <form> element is suppost to be hidden.

Forgot to mentioned that I'm testing this with build 2001061804 win32

error shows on linux 2001 06 18 21

This works on 2001060712, incidentally, so it was broken fairly recently.

Reassigned to HTML Form Controls

is this waiting for bug 34297 as well?

Nope, though I'm interested in it. I was <I>wondering</I> why setting the form to display: none wasn't making it go away.

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

This is not a dup ... 34297 is about submitting form controls, and this one is about laying out <form>. It's not fixed in 34297 and really should be considered a separate issue (i.e. <form style="display: none"> does not hide the form).

John, I am futuring this, but you are welcome to take.

I believe this is because html.css has: form { display: block !important; } change to: form { display: block; } and display: none; is fine. HOWEVER display: inline on <form> still does not behave correctly (Moz 0.9.7)

Rich, thanks!

posted bug 123470 for display: inline;

Please test how "form { display: inline }" works in author sheets with your patch. :)

I've tested it and found to have no effect. I've a testcase at bug 123470 if anyone wants to test

i just noticed, the form declaration in html.css is irrelevant because of rules in forms.css. would it be better to remove the rule altogether from html.css? i tested this on mos 0.9.7. display:none works. display: inline fails

are the rules in forms.css being used? I thought those were used only if xbl form elements are turned on or something like that. I've tested almost all the css display properties that I know will work in moz and they work except for display: inline;

The rules in forms.css are being used. I have changed them and they have affected form control display.

Rod can you please reconsider fixing this bug. All that is needed is to remove the !important from the rule (i'd even suggest removing the rule from the html.css file since it is already included in the forms.css file). I will submit a new bug report for the inline problem (with a testcase) if I can't find a dupe report already submitted because it's a different issue.

Well I found what caused this regression... bug 62811. Rod look at comments #31 and #32 you can see that the reason for the bug report was fixed a different way. From #32: Just as a heads up - I plan on removing nsFormFrame as part of bug 34297. I'm moving all the form submission and management logic to content land, and there is nothing else of interest in nsFormFrame. This should, I think, eliminate the need to change html.css. Again I think that this is safe to remove !important. BTW: no support for form {display:inline} is bug 44470.

Fixed with bug 125578 (bye bye nsFormFrame).

Form element is visible for the testcase being browsed with Mozilla 1.0, Win32 environment.

It isn't fixed for 1.0 and will not be. Use a trunk build.

verified fixed on winXP, linux 8.0 and macos 10.1 with testcase attachment 39119 [details]