272397 - Additional Space below </form> statement (move form { margin: 0 0 1em 0; } to quirk.css)

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Klaas Henschel]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a5) Gecko/20041125
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a5) Gecko/20041125

In the Example the Border should go direct around the Button.
In Mozilla 1.73 and before everything was ok, beginning with 
about Mozilla 1.8x there is additional Space below the Button,
causing tables with multiple buttons not to align.
The Space exist if the /form is in a Table, it is
independant from the action of the button.


Reproducible: Always
Steps to Reproduce:
Put the following Code in a Web Page:

<table border="1">
<tr>
<td>
<form method="post" action="javascript:loadpopup()">
<input type="submit" value="Show Popup">
</form>
</td>
</tr>
</table>
Actual Results:  
Space below Button inside Border

Expected Results:  
Border with no Space direct around the Button

Comment 1

[Justin Wood (:Callek)]

see http://lxr.mozilla.org/mozilla/source/layout/html/document/src/forms.css#50

Looks intended.

Comment 2

[Daniel Wang]

http://lxr.mozilla.org/mozilla/source/layout/style/forms.css#50

Comment 3

[Mike Kaply [:mkaply]]

This is a big deal. I'll try to find what caused it.

Comment 4

[Mike Kaply [:mkaply]]

Regression was between 1.8a2 and 1.8a3

Comment 5

[Mike Kaply [:mkaply]]

Actual date of regression was between builds:

July 15 at 9AM and July 16 at 10 AM

Comment 6

[Mike Kaply [:mkaply]]

Regression was caused by:

https://bugzilla.mozilla.org/show_bug.cgi?id=101084

Comment 7

[Mike Kaply [:mkaply]]

Attachment: My testcase

These buttons should be aligned horizontally.

Comment 8

[Martijn Wargers (dead)]

(In reply to comment #7)
> These buttons should be aligned horizontally.
Why should they? IE6 is not aligning them, neither in quirks mode or standards
mode. The fix for bug 168974 was about removing css quirks that aren't there in IE6.

Comment 9

[Mike Kaply [:mkaply]]

(In reply to comment #8)
> (In reply to comment #7)
> > These buttons should be aligned horizontally.
> Why should they? IE6 is not aligning them, neither in quirks mode or standards
> mode. The fix for bug 168974 was about removing css quirks that aren't there
in IE6.

What was the justification for removing these, though?

What we have now is things that wokred in Mozilla 1.7 and Firefox 1.0, and now
they don't work in current Mozilla builds.

I'll check the code in the IBM app I have to see if they generate different code
for IE 6.

Comment 10

[Martijn Wargers (dead)]

(In reply to comment #9)
> What was the justification for removing these, though?
Before that fix, Mozilla was behaving differently as IE6, now it is behaving the
same as IE6. The quirk css was originally intended to let Mozilla behave the
same as IE6, but instead it did the opposite.

You're right that this makes an odd difference with Mozilla1.7/Firefox1.0, though.
But that means that once you have some quirk css, you can never remove it,
because it will always break older Mozilla versions.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> What was the justification for removing these, though?

Having them in gave us behavior that was incompatible with other browsers (and by implication, 
with existing content, most of which is targeted at those other browsers).  The point of quirks 
mode is compatibility with existing content and other browsers, and the quirk was actually 
working against that.  Hence the removal.

In general, quirks will tend to get removed as the majority of content stops relying on them... so 
relying on them to start with is a really bad idea. 

I think this bug is invalid.

Comment 12

[Mike Kaply [:mkaply]]

Attachment: Better testcase

Actually, our behavior does NOT match IE now. It is actually the opposite of
Internet Explorer. Please try the new attached testcase in IE 6, current trunk
builds, and Firefox 1.0.

You will see three different results.

With form tag not closed:

FF 1.0 - buttons are aligned
IE 6.0 - buttons are aligned
Moz Trunk - buttons are not aligned

With form tag closed

FF 1.0 - buttons are aligned
IE 6.0 - buttons are not aligned
Moz Trunk - buttons are aligned

Comment 13

[Mike Kaply [:mkaply]]

Attachment: Screenshot

Comment 14

[Martijn Wargers (dead)]

The first part of the "Better testcase" testcase is influencing the second part
of the testcase, in both IE6 and also Mozilla seems like it. 
If you would handle those parts in different pages, then you would get different
results.

http://martijn.heelveel.info/test/mozilla/quirkform/first.htm
http://martijn.heelveel.info/test/mozilla/quirkform/output_first_comparison.htm
Mozilla1.7 is rendering the same as IE6 here, trunk Mozilla is rendering
different as IE6.

http://martijn.heelveel.info/test/mozilla/quirkform/second.htm
http://martijn.heelveel.info/test/mozilla/quirkform/output_second_comparison.htm
Mozilla1.7 is rendering different as IE6, trunk Mozilla is rendering the same as
IE6.

http://martijn.heelveel.info/test/mozilla/quirkform/both.htm
http://martijn.heelveel.info/test/mozilla/quirkform/output_both_comparison.htm
Mozilla.17 is rendering the first one the same as IE6 and the second one
different as IE6. Trunk Mozilla is both rendering different as IE6. 

Directory listing:
http://martijn.heelveel.info/test/mozilla/quirkform/

I knew that IE6 is acting rather strange with unclosed <form> tags (resulting in
this kind of behavior).
But Mozilla is also not really acting 'normal' -> In the second part of the
testcase of 'both.htm' no <form> element is around the <input> element. 
You would expect this to happen, because this is happening in 'second.htm', and
I would expect that the parsing of the second part of 'both.htm' is the same as
'second.html'. 

Comment 15

[Boris Zbarsky [:bzbarsky]]

The behavior of IE in the "form tag not closed" case can't really be done in Mozilla, and 
we don't have plans to do it.  There are very old invalid bugs on that.

I'll look into why the two parts of the testcase interact with each other....

Comment 16

[Boris Zbarsky [:bzbarsky]]

Actually, things are working "as designed".  An unclosed form tag means the form stays 
open; we don't allow anything else to close forms, since forms are commonly left open 
that way and expected to remain open.  Any new <form> tags encountered before a 
<form> is closed are ignored.

Note that IE is doing really bizarro things here (there are 6 inputs in the DOM, but only 4 
are rendering; there are nested <form> tags and other random <form> nodes elsewhere, 
etc, etc).

I don't think we want to reverse-engineer the IE DOM here, especially since it's likely that 
IE's submission behavior is somewhat divorced from the DOM.

So I'd say this is either invalid or wontfix...

Comment 17

[Mike Kaply [:mkaply]]

Attachment: Testcase from IBM product for posterity

For posterity, here is the actual code from an IBM product that is failing.

Anyone have a clue as to why someone would write code that closes a form before
opening it?

Doron said it was to work around an IE 5.5 bug.