Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007111705 Minefield/3.0b2pre ID:2007111705 Filed on behalf of Chainfire from IRC. 1. New profile, start firefox 2. Load testcase 3. Observe 'Some text here' box at top Expected: - Text line should be 1px higher to match other browsers Actual: = Text line is 1px too low

Rendering the same as other browsers: - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007030411 Minefield/3.0a3pre Rendering 1px too low: - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007030415 Minefield/3.0a3pre Checkins to module PhoenixTinderbox between 2007-03-04 10:00 and 2007-03-04 16:00 : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-04+10&maxdate=2007-03-04+16&cvsroot=%2Fcvsroot Due to bug 370588?

Windows only?

(In reply to comment #2) > Windows only? > Nope -- I see this on Linux.

So, for a 2px increase in line-height, the text shifts down by 1px. (because it's centered in the line, I think.) This is true on both FF2 and FF3. The difference, though, is *which* 1px increase out of the 2 will trigger the text to shift down by 1px. Looking at this testcase, here's the difference between FF2 and FF3 (on Linux) FF3 on Linux: text moves when line-height increases from ODD to EVEN FF2 on Linux: text moves when line-height increases from EVEN to ODD In more detail: - For odd line-heights, FF2 and FF3 agree - When we step up 1px, to an even line-height, FF3 shifts the text down by 1px, and FF2 doesn't, so they disagree. - When we step up another 1px, to an odd line-height, FF2 shifts the text down by 1px, and FF3 doesn't. So FF2 "catches up" to FF3, and they agree again.

(In reply to comment #6) > Looking at this testcase, here's the difference between FF2 and FF3 (on Linux) > FF3 on Linux: text moves when line-height increases from ODD to EVEN > FF2 on Linux: text moves when line-height increases from EVEN to ODD Windows is the same as Linux for the FF2/FF3 difference here. FF3 on Windows: text moves when line-height increases from ODD to EVEN FF2 on Windows: text moves when line-height increases from EVEN to ODD But interestingly, Mac is the exact reverse FF3 on Mac: text moves when line-height increases from EVEN to ODD FF2 on Mac: text moves when line-height increases from ODD to EVEN Here are results on other browsers, FWIW: IE7 on Windows: ODD to EVEN Safari on Mac: ODD to EVEN Konqueror on Linux: EVEN to ODD Opera on Linux: EVEN to ODD

I actually get consistent results between FF2 and FF3 on all of Mac, Windows and Linux. Has this been fixed recently? In any case, we've never guaranteed pixel-consistent baseline positioning and I don't think we should start guaranteeing that, so I'm pretty tempted to mark this not blocking.

Problem still exists on Minefield 2008-01-07 (just tested). As for 'never guaranteed pixel-consistent baseline positioning' and making it non-blocking; That's all very well for you to say, but some of us have to make pages that look nice crossbrowser too, this move would make that impossible. An odd line-height is the only way to make fonts look good and consistent across the 4 major browsers on the 3 major platforms (yes, even with Safari's font rendering system). Ok, that's not entirely true, you need to add a CC-based fix for IE6 (but hey, what piece of good-looking CSS doesn't require that?). It wouldn't be a problem if Firefox supported CC's as well, but this has been deemed bad practise and to some point I agree with that; however, in the real world there is sometimes no escaping it. Graphically intensive and crossbrowser nice looking pages are already a PITA to make now (yes, sometimes that is what is called for), why not make your job easier and our job harder? Besides, who ever cared about consistency? Stuff like this makes people use Flash, is that what we want?

I'm also seeing this bug with the first testcase, with current trunk windows build.

> Stuff like this makes people use Flash, is that what we want? Of course not, but that doesn't mean we should turn HTML+CSS into a pixel-accurate page description language. SVG is the Web-standards solution for that. I'll see what I can do, but I have to be able to reproduce it first.

(In reply to comment #9) > Problem still exists on Minefield 2008-01-07 (just tested). Same here -- to be more specific, I still see buggy behavior on both the original testcase and on testcase 2 (as described in Comment 7) using a Linux trunk build from 2008-01-07.

Daniel, do you want to take this?

(In reply to comment #13) > Daniel, do you want to take this? > Sure. --> Stealing.

Here's a CSV spreadsheet of FF3 and FF2's behavior on testcase 3, with various "font-size" values. "Yes" means that the text moves on the first click; "No" means that the text doesn't move until the second click. Notice that FF3 and FF2 have the same behavior for all font-sizes *except* for 2px-16px. (16px is the default height, at least on my Linux machine) The builds I tested were: FF2 = Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12 FF3 = Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020708 Minefield/3.0b4pre

I didn't notice it before, but the differences in rendering for font-size: 2px to 16px described in comment 16 are actually due to the *inital conditions* -- for those font sizes, FF2 starts the text out 1px higher than FF3 does. I'm pretty sure that's happening due to rounding errors because we have fewer app-units per pixel in FF2. On my system, FF2 uses 15 app-units per pixel, whereas FF3 uses 60. In the starting conditions of testcase 3, the text is at y-position = 1/2px. In FF2, this is 7 app-units, which in actuality is *less* than 1/2px. In FF3, this is 30 app-units, which is *exactly* 1/2px. For small fonts (i.e. those less than 16px tall -- see comment #16) the difference between a exactly-half-a-pixel and slightly-less-than-half-a-pixel could make a difference in the positioning of the text. Gonna do a bit more testing to verify this, but I'm pretty sure that's what's going on. (and as a result this is probably not a bug.)

(In reply to comment #17) > Gonna do a bit more testing to verify this, but I'm pretty sure that's what's > going on. (and as a result this is probably not a bug.) Yup -- in all the situations I'm seeing where FF2 and FF3 differ in this respect, the text is at a Y-position that's 7appUnits off of 1px -- e.g. it's at 7, or 22, or 37, or 52, etc. In these situations, FF2 places the text 1px higher than FF3, due to the loss of precision in rounding 1/2 px = 15/2 = 7. This is true of the original testcase, testcases 2, and for testcase3 with a variety of font-sizes that I tested. (For the fontsizes where FF2 == FF3, the text's y-position was always an even pixel value -- 15, 30, 45, etc) So -- I'm chalking this bug up to a rounding error in FF2 that's been corrected by the higher precision in FF3's app-units. Resolving as invalid, since it's not a bug in FF3.