User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 Firefox 3 (tested under Linux, Win XP) does not render page correctly, while Firefox 2 and other web browsers (Konqueror, IE 6,7,8, Opera..etc) do it as it should work. Reproducible: Always Steps to Reproduce: 1. Go to http://domainlord.co.uk/forsale/radio.co.uk with Firefox 3 2. Go to http://domainlord.co.uk/forsale/radio.co.uk with Firefox 2 3. See the difference in formating (contact e-mail) Actual Results: Formating problem Expected Results: Results as in FF 2.0 or any other browser Occurs since Firefox 3

Regression range for this is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-04-20+14%3A00&maxdate=2006-04-20+20%3A00 bug 132561 or bug 309433 ?

This might be invalid, I'm seeing the same problem occuring in Opera9.5. The <br> should be <br clear="all"> to make it look correct again.

weird, but this also affects Opera 9.5 All other browsers, including previous versions of Firefox render it properly. I've tested using http://browsershots.org and attach a couple of screens

All I see is a broken page, no bugs. This article might shine some light over the behavior http://friendlybit.com/css/finer-details-of-floats/ Specifically this snippet > 2. #child2 must be to the right of #child since #child is earlier in the source. If there is not enough space to the right of #child, #child2 must be moved below #child2 instead. @Martijn Wargers The thing with the border sounds like a bug. Though I don't see that behavior here so it's probably fixed, using Gecko/2008071222 Firefox/3.0.1 ID:2008071222 @Denys Four ways I can think of to fix the page. Use display:inline-block on the label and display:inline-block or inline on the input. Use clear:left on the label and float:left on the input. Use (as already said) clear:left on the <br>. Use padding/margin/height to make the input taller than the label.

So the issue is that the floating text is taller than the textfield (by 5/12 of a pixel). Note that this will happen any time "1.8em" of the user-default font in the font that's used for the text is more than the 18px font used for the text input plus the various borders of the text input, etc. In particular it will depend on the _exact_ subpixel metrics of the two fonts involved. The behavior change from 1.8 to 1.9 happened in the range 2006-04-20-01 to 2006-04-21-00 on Linux. The checkins are: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-20+01&maxdate=2006-04-21+00&cvsroot=%2Fcvsroot I have no idea what exactly in that range would have caused this change in behavior....

Oh, interesting. This is a regression from bug 132561. If I no longer skip <br> when trimming whitespace, there is no problem. This is the case whether there is in fact any whitespace to trim or not, in fact. Did the <br> use to contribute to the height somehow and not do so any longer? Should it?

I don't see how whitespace trimming can change heights, so I'm not sure what's happening.

Well, one difference is the TextFrame for the \n right before the <br>. When it's not trimmed, we have: Text(3)@0xe02950[0,1,T] next=0xe029e0 {33000,0,432,1800} [state=02000000] [content=0x16cce080] sc=0xe02054 pst=:-moz-non-element< "\n" > When it's trimmed, we have: Text(3)@0xe13150[0,1,T] next=0xe131e0 {33000,-43,0,1800} [state=02400000] [content=0x1dfac740] sc=0xe12854 pst=:-moz-non-element< "\n" > Note the difference in vertical position (which hence affects the line box).

And on Mac (which is where I am now), removing the \n does in fact make my build that doesn't trim whitespace also "fail", though Firefox 2 still passes. So we might need a separate regression range for the case when there is no newline before that <br>.

I take that back. If I take out the newline, Firefox 2 acts like Firefox 3. So the Firefox 2 behavior depends on whether there's a newline there or not, which seems pretty buggy to me.... One other thing. The behavior is definitely quirks-mode specific. In standards mode, Firefox 3 makes the line box tall enough no matter what the \n is doing. So does Firefox 2. So I bet the issue is that trimming whitespace makes us think we have an empty span and so don't need to insert a strut for the parent font-size or something like that to do with the quirks inline model?

I don't fully understand what you were saying, so I might be repeating things here. This is what I see in Fx3, same build as earlier. In quirks-mode, the input is only affected by the line's height if there is some sort of text content (text node?) in the same container, in this case whitespace. The testcase uses a normal space but a newline or any other character has the same effect. In strict mode, the input is always affected by the line's height. So, not really a bug, but the behavior in quirks-mode could probably be changed? Another thing that seems to happen is that whitespace at the beginning and end of a container are ignored? I say ignored, because the content is visibly affected by the whitespace, but the behavior only kicks in when it's placed between the inputs.

Sounds like we're talking about the same thing. The point is, in Firefox 2 a newline before a <br> was treated the same way as space between the inputs. In Firefox 3 it's treated like space at the start of the line or end of the container. The quirks mode behavior of not taking into account trimmable whitespace is sadly required for things like image slicing into tables to work "right". So it's not easy to change...

I hope you notice your spelling is off... Anyway, is this truly a bug that we should fix, or WONTFIX

This is still repro on nightly 26.0a1 (2013-08-21) using the first testcase. Re-add qawanted if you need further qa help.

As stated in comment 16, this issue is still reproducible Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Is this an issue that will be fixed or should we close it as wont fix?

I have no plans to work on this myself, but imo it should in fact be fixed. Probably as part of the larger whitespace and inline layout overhaul we desperately need....